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_.
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.
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.
Edward Haber wrote:
>
> 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.
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.
