[dev] Autoloading application rdo objects

Chuck Hagenbuch chuck at horde.org
Tue Nov 17 05:00:57 UTC 2009


Quoting Jan Schneider <jan at horde.org>:

> Zitat von Chuck Hagenbuch <chuck at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Duck <duck at obala.net>:
>>>
>>>> As the current implementation of RDO requires the object mapper  
>>>> to have the
>>>> "Mapper" suffix after the object name. Hot to make them autoload-able?
>>>
>>> I my (private) application, I name them like App_Rdo_FooMapper and  
>>> have all the Rdo classes in the app/lib/Rdo/ directory. This only  
>>> works for a small set of classes though, because you end up with a  
>>> lot of files in this directory otherwise.
>>>
>>> We should probably use a different name scheming that better fits  
>>> our autoloading scheme. Maybe App_Rdo_Mapper_Foo so that all  
>>> mapper classes are in app/lib/Rdo/Mapper/. Though this wouldn't  
>>> group the classes thematically, just by function.
>>> The other option would be App_Rdo_Foo_Mapper, but that would lead  
>>> to a lot of app/lib/Rdo/Foo/ directories, all only containing the  
>>> Mapper.php file.
>>> A third solution could be to also name the Rdo base classes  
>>> differently, so that we have App_Rdo_Foo_Mapper and  
>>> App_Rdo_Foo_Base (or _Object). That's the cleanest solution on the  
>>> filesystem level IMO, because we have a lib/Rdo/ directory that  
>>> only contains directories, and all these directories group the Rdo  
>>> base and mapper classes thematically. The resulting base class  
>>> name is less beautiful though.
>>
>> I'm in favor of eventually having something like:
>>
>> lib/Mappers/
>> lib/Objects/
>>
>> (I'm not happy with just "Objects", though - maybe "Entities"?)
>>
>> And then adding new autoloading rules that look for a class named  
>> App_FooMapper in app/lib/Mappers/Foo.php, and looks for  
>> App_FooEntity in app/lib/Entities/Foo.php. One of my coworkers has  
>> a rewritten autoloader that allows swapping in new autoloading  
>> strategies seamlessly, so this wouldn't be hard to set up in the  
>> app initialization logic.
>
> If we rely on a different autoloading scheme anyway, I'm in favor of  
> grouping the mapper and object classes into functional directories,  
> i.e. rather:
>
> lib/Contact/Mapper.php
> lib/Contact/Object.php
>
> This is more intuitive when locating certain functionality in the  
> source tree.

Hmm, maybe. I'm not sure about that one.

>> I'm still not happy with the Entity/Object name though - any ideas there?
>
> I think Object is quite fine. After all it's the o in Rdo.

Fair enough - convinced on that.

-chuck


More information about the dev mailing list