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

[Luis Felipe Marzagao]

Em 16/07/12 02:47, Ralf Lang escreveu:
> -----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.

Great, things are a lot clearer now!! Thanks a lot.

> - -- 
> 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-----