[dev] Rdo questions was: Pastie Pastebin app status: Runs on H5, but won't release.

[Ralf Lang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi,

> * use a factory class instead of the factory in the base driver
>> Since horde has a dependency injection framework, shouldn´t rdo
>> entity mappers be instantiated like:
> 
>> $GLOBALS['injector']->getInstance('Appname_EntityMapper');
> 
>> This way there´s no need to worry about creating or passing
>> around the adapter object (the one needed by
>> Horde_Rdo_Mapper::__construct), since it is automatically
>> provided by the framework.
> 
>> Also, the getInstance method from injector would already take
>> care of avoiding returning new Mapper objects, considering it
>> already works with the dependency injection container. So, my
>> question is if it is necessary to use a rdo factory method for
>> instantiating entity mapper objects rather than just using
>> getInstance from global injector.
> 

Just to make sure we're not confusing things:

* Horde_Rdo_Factory is completely optional.

You can directly create mapper objects by manually supplying the db
adapter or you could create an application wide specific factory
method for your adapter.

However, there are instances when Rdo needs to create a new mapper of
a different type internally when mapping relations. We do not use
injector inside library code. I created an app for a customer where
there was a huge performance boost through this method. This might not
apply to your use case

* Pastie_Driver_Factory

This is what the comment applied to. Pastie had a factory method
inside Pastie_Driver base class which created backends and their
dependencies in place. Horde 4/5 code usually has a separate factory
class instead.

> * Create a horde 5 compatible driver based on Rdo (less work than 
> converting the Sql driver to Horde_Db).
>> Is it correct to assume the rdo stuff works only as an
>> abstraction layer for the Horde_Db_Adapter_... and, thus, will
>> only manipulate sql backends? If this is correct, than why is it
>> necessary to create a separate rdo driver for the application?
>> Shouldn´t it be "blended" wih the sql driver or, better saying,
>> be automatically selected when the administrator selects "sql" as
>> the driver for the application?

Rdo is a Db abstraction layer. When I created the first Rdo based
driver for sesha, we had a discussion on the list and agreed it should
be called Rdo, not Sql.

I simply chose Rdo instead of manual sql because it saves tedious work
without any visible benefits.

The Sql driver in pastie is the unchanged PEAR DB driver. It will
probably not work at all and can be removed.

- -- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang at b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAlADqvEACgkQCs1dsHJ/X7BvZACY7HEgVS+oLI9u/uuA3P9+f4aM
0ACg5FAiMIpq6FPPxDrlWPJiIXZTv4w=
=tyP1
-----END PGP SIGNATURE-----