Totally agree with you. I actually implemented something very similar
on my last project, having reusable modules in the library that were
added as svn externals. I'm about to start a new project and was
wondering if I made the right decision to put it in the library folder.
Sounds like we are on the same page, but a standard would be even
better, this way when once the community has a large set of modules to
share we are all following the same structure.
Another way of having reusable modules show that they are external and
still have them inside the application folder is to use a different
namespace. The different namespace would be indication to where the
code came from. Unfortunately until I migrate to 5.3, which might
happen sooner now that I have seen ZF 2.0 roadmap, adding anything extra
to the already too long classname might also make it a distraction.
On 12/23/2009 2:02 AM, Simon R Jones wrote:
hi Paul,
We have the same requirement at Studio 24: basically wanting to store
a re-usable module which has core, usually non-editable code which can
then be extended/customised for a client project.
I agree the normal ZF modules don't really cover this use case. At
present we place this kind of reusable module in "library/Modules". A
brief explanation of how we use it is below (an email originally sent
to the contributors list). It's something I plan to write a blog post
on soon to get feedback from others. Hopefully early in Jan :)
Some sort of standard for reusable modules in ZF would be helpful to
encourage sharing of modules in the community, if this use case is
agreed to be common enough to need it. I personally think this kind of
pluggability would be really useful.
The second requirement we have is to have re-usable modules that we
can install for a client, customise, and ideally upgrade in the
future if we have a bug patch. The classic use case being user
management.
To do this we have a library/modules/ folder. This has sub-folders
which basically contain a full MVC app with the normal ZF folder
structure. I.e. for user management this has library/modules/user
When used for a client site we SVN external the library/modules
folders and treat this codebase as non-changeable (so we can update
it in the future if we wished to). We then have some Zend_Application
code which sorts out the autoloading and simply extend a few skeleton
controllers in the normal app/modules/ folders to actually hook into
the library module functionality.
So app/modules/user/controllers/LoginController.php will extend
library/Modules/User/application/default/controllers/Login.php
We also have a view helper which looks in the library/modules folder
first for views, then can be overridden by the local app/modules folder.
This idea of organised admin modules/URLs and extendable library
modules is one we've struggled a little with recently but is very
important to a web agency like us who develop a lot of common stuff
for clients - and need to customise it on a project-by-project basis.
Zend Framework has been good for us in many ways, it's just sometimes
difficult working out the best way to achieve this kind of re-usable
module setup.
On a final note the cascade is important in this scenario, local
controllers need to override the base controller, local views need to
override the base views, so the developer is always able to override
functionality/view if they so desire. I've used Kohana framework a bit
which has a nice cascade system.
best wishes,
Simon
On 23 Dec 2009, at 05:49, Paul wrote:
I know this has been discussed before, but was is the best way to
handle external modules?
I not asking for a place to find modules or for ZF to have a site
dedicated to modules, just want to know what the standard is for
installing a module into your existing system.
To me the library directory in the project structure makes it very
obvious that the classes inside are used as a base library of classes
for your application.
By having external modules in your application directory, it makes it
harder for someone who is less familiar with the history of the
project to know that the code in the "acl" module is external when
compared to the "user" module which was created inside the project.
I guess the issue comes to maintaining a system. As a developer
working on a project you do not want to edit core / external code.
For example if I need to alter the Zend_View, i just don't go into
that class and alter it's behavior. I can use view helpers or extend
the class. As a developer its clear that code in the library folder
should not be touched. In the example above, the new developer
would not want to touch the acl module as it is external to the
system, whereas the user module is okay.
It comes down to what do we think a Zend Framework module is? A self
contained group of code that can be dropped in to any ZF app? Or is
it just a better way to organize and set the boundaries your
applications domain? Should we have another folder under the root of
the project .. maybe extensions ?
I know of ways to achieve this, but I feel, like many others, that
the next big step for ZF (besides v2.0), are 3rd party
modules/extensions/plugin (like joomla, wordpress, drupal, jquery,
etc), and I don't want to break away to much from the standard
project structure to make it as easy as possible to upgrade.
cheers,
pbo
