[dev] Autoloading application rdo objects

[Chuck Hagenbuch]

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.

I'm still not happy with the Entity/Object name though - any ideas there?

-chuck