Re: Shared Models in Different Modules

I'll chime in here with some contextual background, perhaps that might
help you understand the ideas at play.

One important notion to keep in mind is the difference between library
layer code and application layer code.  Essentially, all Zend Framework
components are considered "library" code.  They are unit testable, live
in a very well defined pseudo-namespace and as such are named according
to the pseudo-namespace rule.  IE: Zend_Loader is Zend/Loader.php.  The
reason this works so well is b/c there is a requirement that ZF exists
inside PHP's include_path.

On the other side of the coin is the application layer code.  This
includes (But is not limited to current) View Scripts, Controller
Scripts and Models.  Typically, in ZF's MVC file structure, they can be
found in ./moduleName/views/, ./moduleName/controllers/, and
./moduleName/models/ respectively.  Bear in mind, these paths ARE NOT i
your php-inclue path.

Moving along, (this is a matter of personal taste), I prefer model
purism in my model classes and objects.  This means that I typcially
name my models (for example): Blog_User.  This means that the model
class User exists within the realm of the Blog module.  This naming
convention keeps the class names away from collisions as well as
provides the simplest cleanest name for my application to reference.

Another note (from my personal perspective), is that is A GOOD THING (r)
that the word controller is in the controller file name as that removes
itself from potential confusion between model file names and controller
files (its serves as a visual cue).  But that can be argued either way.

ALL OF THAT SAID: there is a solution for loading classes and files at
runtime that do not exist inside PHP's include_path.  If you look in the
incubator, you will see Zend/Loader/PluginLoader.php.  It will be
documented over the next week and half, and I think you will find it
immensely useful when it comes to loading application-layer code with
arbitrary (developer friendly) namings in arbitrary (again read:
developer friendly) file locations.

The future of ModelLoader btw, will be revisited once PluginLoader is
fully documented.

Hope that helps,
Ralph

AmirBehzad Eslami wrote:

> That's exactly what i am talking about it, and, yes, it requires a
> massive shift.
>
> Why should we use:
> $this->_helper->ModuleLoader('News_Story');
> instead of:
> Zend_Loader::loadClass('News_Story');
> ?
>
> To achieve this, we should follow a consistent naming scheme
> among controllers and models, and that scheme should be compatible
> with Zend_Loader.
>
> Forget the models for a moment, but the inconsistency still remains:
> *Currently, we name our controllers X_Y_Z,
> but we store them in X/controllers/ZY.php !*
>
> What's wrong with: X/Y/Z.php ? It's compatible with Zend_Loader.
>
> Zend_Loader and its scheme is created to facilitate loading classes in a
> Modular-MVC architecute, whereas it is currently unable to achieve this,
> because of inconsistent naming schemes.

>
> Zend_Loader::loadClass('Foo_Controller_Bar');
> // loads: foo/controllers/bar.php
>
> Zend_Loader::loadClass('Foo_Model_Bar');
> // loads: foo/models/bar.php
>
> Not only this naming scheme keeps the directory structure which is
> recommend in the manual, but also it allows the Zend_Loader to load
> every class in the MVC-architecture, and no patches is required.