Autoloading application rdo objects

[duck-3]

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?

Duck

--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Jan Schneider]

Zitat von Duck <duck@...>:

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

Jan.

--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/


--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Chuck Hagenbuch]

Quoting Jan Schneider <jan@...>:

> Zitat von Duck <duck@...>:
>
>> 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

--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Jan Schneider]

Zitat von Chuck Hagenbuch <chuck@...>:

> Quoting Jan Schneider <jan@...>:
>
>> Zitat von Duck <duck@...>:
>>
>>> 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.

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

Jan.

--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/


--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Chuck Hagenbuch]

Quoting Jan Schneider <jan@...>:

> Zitat von Chuck Hagenbuch <chuck@...>:
>
>> Quoting Jan Schneider <jan@...>:
>>
>>> Zitat von Duck <duck@...>:
>>>
>>>> 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

--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...