Why does Zend_Application_Module_Autoloader specifically look in /models/dbTable/?

[Artsemis]

Before you jump right to a response, let me clarify this question a bit:

The Zend_Application_Module_Autoloader automatically checks for classes starting with Namespace_Model_ in the /models/ directory and it also checks for classes beginning with Namespace_Model_DbTable_ in the /models/DbTable/ directory... but wait...

I think we can all agree on the following:
Namespace_Model_Person => /models/Person.php

And because underscores translate into directories, we should all agree that:
Namespace_Model_Testing_Person => /models/Testing/Person.php

And by the same rule:
Namespace_Model_DbTable_Person => /models/DbTable/Person.php


So, why is it that Zend_Application_Module_Autoloader [b]specifically[/b] checks for DbTable classes in the /models/DbTable/ class?  Unless I'm missing something, this specific check is redundant as the underscore in the class name indicates that "DbTable" is a subdirectory of /models/ anyways so it's not necessary to specifically check it.

[prodigitalson]

Artsemis wrote:

So, why is it that Zend_Application_Module_Autoloader [b]specifically[/b] checks for DbTable classes in the /models/DbTable/ class?  Unless I'm missing something, this specific check is redundant as the underscore in the class name indicates that "DbTable" is a subdirectory of /models/ anyways so it's not necessary to specifically check it.

Because the module autoloader follows the format of a plugin loader - which youve probably noticed doesnt follow the the same mapping convention but rather allows you to arbitrarily map namespaces to file system locations. Im assuming this is to add flexibility because you might not always want plugins to rely on the hard class name -> path mapping. Im sure there are a number of uses cases for this.

However i think it would be mighty handy to have an option to say "useAsBase" or something and then form the the specified mapping down if follows standard Zend/Pear conventions... This makes it a lot easier to keep things organized. For example if youre doing Rowset/Row classes as well as Tables its a lot nicer to have the traditional package structure:

models/DbTable
  /Row
  /Rowset

currently if you want that i believe you have to add namespaces explicity to the module autoloader/plugin loader. Unless im missing something somewhere... This cant be an uncommon use case either...

[Brenton Alker-3]

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

prodigitalson wrote:

>
> Artsemis wrote:
>> So, why is it that Zend_Application_Module_Autoloader [b]specifically[/b]
>> checks for DbTable classes in the /models/DbTable/ class?  Unless I'm
>> missing something, this specific check is redundant as the underscore in
>> the class name indicates that "DbTable" is a subdirectory of /models/
>> anyways so it's not necessary to specifically check it.
>>
>
> Because the module autoloader follows the format of a plugin loader - which
> youve probably noticed doesnt follow the the same mapping convention but
> rather allows you to arbitrarily map namespaces to file system locations. Im
> assuming this is to add flexibility because you might not always want
> plugins to rely on the hard class name -> path mapping. Im sure there are a
> number of uses cases for this.
>
> However i think it would be mighty handy to have an option to say
> "useAsBase" or something and then form the the specified mapping down if
> follows standard Zend/Pear conventions... This makes it a lot easier to keep
> things organized. For example if youre doing Rowset/Row classes as well as
> Tables its a lot nicer to have the traditional package structure:
>
> models/DbTable
>   /Row
>   /Rowset
>
> currently if you want that i believe you have to add namespaces explicity to
> the module autoloader/plugin loader. Unless im missing something
> somewhere... This cant be an uncommon use case either...

Actually, it maps the namespace to a directory, after that it uses the
standard convention. I often use things like:
 models/Entity/ -> App_Model_Entity_*
 models/Collection/ -> App_Model_Collection_*
 models/Collection/Proxy -> App_Model_Collection_Proxy_*
 etc...
in my applications without any explicit mapping (ie. just instantiate a
module autoloader in the bootstrap for the "App" namespace, as suggested
in the docs).

So I think the original question is a good one, why the explicit
inclusion of models/DbTable? Is it for efficiency or clarity of a common
use case? If not, should it be removed?

- --

Brenton Alker
PHP Developer - Brisbane, Australia

http://blog.tekerson.com/
http://twitter.com/tekerson

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrwvtwACgkQ7bkAtAithuuObQCbB7PHx/SrLTiB/Qurbqix5Pts
UNMAoMgj2QW1ZL3n+Ij8SPl+hiAgy5pl
=E7sQ
-----END PGP SIGNATURE-----

[weierophinney]

-- Brenton Alker <[hidden email]> wrote
(on Wednesday, 04 November 2009, 09:38 AM +1000):

> prodigitalson wrote:
> > Artsemis wrote:
> > > So, why is it that Zend_Application_Module_Autoloader [b]specifically[/b]
> > > checks for DbTable classes in the /models/DbTable/ class?  Unless I'm
> > > missing something, this specific check is redundant as the underscore in
> > > the class name indicates that "DbTable" is a subdirectory of /models/
> > > anyways so it's not necessary to specifically check it.
> > >
> >
> > Because the module autoloader follows the format of a plugin loader - which
> > youve probably noticed doesnt follow the the same mapping convention but
> > rather allows you to arbitrarily map namespaces to file system locations. Im
> > assuming this is to add flexibility because you might not always want
> > plugins to rely on the hard class name-> path mapping. Im sure there are a
> > number of uses cases for this.
> >
> > However i think it would be mighty handy to have an option to say
> > "useAsBase" or something and then form the the specified mapping down if
> > follows standard Zend/Pear conventions... This makes it a lot easier to keep
> > things organized. For example if youre doing Rowset/Row classes as well as
> > Tables its a lot nicer to have the traditional package structure:
> >
> > models/DbTable
> >   /Row
> >   /Rowset
> >
> > currently if you want that i believe you have to add namespaces explicity to
> > the module autoloader/plugin loader. Unless im missing something
> > somewhere... This cant be an uncommon use case either...
>
> Actually, it maps the namespace to a directory, after that it uses the
> standard convention. I often use things like:
>  models/Entity/-> App_Model_Entity_*
>  models/Collection/-> App_Model_Collection_*
>  models/Collection/Proxy-> App_Model_Collection_Proxy_*
>  etc...
> in my applications without any explicit mapping (ie. just instantiate a
> module autoloader in the bootstrap for the "App" namespace, as suggested
> in the docs).
>
> So I think the original question is a good one, why the explicit
> inclusion of models/DbTable? Is it for efficiency or clarity of a common
> use case? If not, should it be removed?

"Clarity of a common use case" is the operative phrase here. It's not
technically needed, but it makes it explicit at the autoloader level
what types of classes will be found in what locations.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/