First of all, had I known you were a Zend engineer I probably wouldn't
have opened my big mouth. I'm new to the list. :-) But since it's
already open, i'll just offer a few points of view from my perspective.
On Sep 22, 2008, at 12:55 PM, Bill Karwin wrote:
Edward Haber wrote:
Another problem with the proposed solution is that it only makes one
module's models path active at a time. I think the ideal when working
with multiple modules is to have the option of using model code from
more than one module models directory at a time, especially in cases
of interdependency.
No, that's not ideal, that's actually what I was recommending to
_prevent_.
I see your point that having all the models directories of all modules
in the include path leads to namespace collision in a modular
framework like Joomla. I was under the impression you were making a
modular application where the code is grouped by functionality rather
than a third-party-capable modular framework.
A module has its own controllers and views, and should have its own
set of
models as well. One module should not be allowed to reference another
module's controllers, views, or models. If you follow this rule,
then it
solves all the problems of ambiguity and collision.
In my opinion, if you have three modules implementing a Pages model
that has a duplicate "fetchMyPages()" method (say with differing
parameters per module) then it seems anti-DRY to repeat the same file/
class/method three times (then keep them sync'd when making bug fixes,
then write three sets of test classes, etc.). It comes down to (for
me) if the class in question is used in the exact same context in
multiple modules. If it's three unrelated types of pages that has one
solution. If it's three versions of basically the same class and
methods then it seems anti-DRY to me.
Don't separate your application into modules if the modules aren't
separate.
If you want to share model classes among all your controllers, then
don't
create modules.
In my case, It was a lot easier to manage the front-end (controllers
and views) within modules but just use a single model directory. This
particular organizational method helped the front-end developers find
code more easily and allowed for teams to work more independently.
These solutions are unique to the needs of each application. If it
best suited your application, there's no reason you couldn't have
fifty front-ends (of controllers/views) connected to one set of models.
It also suited the application well, which has three front-end areas
(which I made modules) where users of one area never are users in
another area. I agree I would approach a Drupal/Joomla-like
architecture differently, but this architecture is clear, obvious, and
breaks no MVC conventions.
If however it is a must that you remain encapsulation and that these
modules are dropped into other apps and need to work this way, then I
would change the names of your models entirely.
This doesn't work in general, if you drop third-party modules into
your app,
or drop your module into someone else's app. Only if you have
control over
the class naming of all modules in an app does your recommendation
work. If
you're the author of all the modules in the app, then why are you
using
modules at all?
The purpose of modules is to provide isolation between sets of
classes.
Many people seem to use modules to create friendly URL's like
"/myapp/admin/controller/action" but you can do this by creating
custom
router rules. You don't have to use modules simply to define URL's.
This seems unnecessarily strict. In my opinion, modules can be *more*
than this or *less* than this depending on the requirements of the
application. Part of the beauty of the Zend Framework (and PHP) is
that it is so flexible to different architecture requirements. I agree
it's really not that hard to write a route. I'm using plenty of them
in the app. But why not, if it suits the grouping of your code, and
makes the urls work, take advantage of built-in features of the
framework?
Thanks for your notes. I hope to learn a lot from the members of the
list.
Eddie
Regards,
Bill Karwin
--
View this message in context:
http://www.nabble.com/multiple-models-with-same-name-%28m1-models-pages.php-and-m2-models-pages.php%29-tp19607614p19612115.html
Sent from the Zend Framework mailing list archive at Nabble.com.