Re: Shared Models in Different Modules

This is one of the things that has made me a sceptic of the whole concept of
modules. Several people here has spoken about the copy & paste nature of
modules, but I have yet to see this actually work.

If a module would be completely stand-alone, that's one thing, but if you
start creating "shared" modules, such as a User module, things start to
unravel. Once you introduce dependancies between modules you loose the point
of having them in the first place: them being isolated, stand-alone
packages.

For example:

You develop a User module, which in turn is used by a Blog module. You add
functionality to display user profiles to your User module, and, what the
heck, the ability to display the user's blog posts. Now you've ended up with
two modules that each depend on each other. It's not possible to drop either
one into a new project without also including the other. If you've
introduced even more modules and dependancies, say a News module which also
depends on the User module.. Yeah, you get the picture.

Modules seem to be an organisatory tool at best, or rather, that's my
experience. They might work when each module is a separate "application"
that never interacts with anything outside of itself, but I've yet to work
on such a project. :)

I'd love to hear from other ZF developers on this topic.

Regards,
Jens Ljungblad

digitalus_media wrote:
>
> I also agree with the other posts that suggested setting up a users
> module.
>
> If the table is a real core table that many different models will both
> read and write to (like content in a cms) I would suggest setting up a
> core model, then extending this with your module's models.  this way your
> news model can write to the content model, but enforce news specific
> logic.
>
>
>
> mmaru wrote:
>>
>> Let say we have a user table in the database used by the website that has
>> different modules - blog, news, forums, etc. Where will you put the user
>> class module in the application that is going to be used by all the
>> modules?
>>
>> Regards,
>>
>> Maru
>>
>> Ralph Schindler wrote:
>>>
>>> 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.
>>>
>>>
>>>
>>
>>
>
>

--

View this message in context: http://www.nabble.com/Shared-Models-in-Different-Modules-tp14117646p16734950.html

Sent from the Zend MVC mailing list archive at Nabble.com.