How about "global" forms/helpers/filters? My current structure follows:
application/
configs/
filters/
forms/
helpers/
modules/
blog/
controllers/
helpers/
Where the top-level filters/forms/helpers directories contain things
that are, or could be, used by multiple modules, such as a helper that
sets up variables used by every view script, a login form, and a
"stripslashes" filter.
Is there a best practice for handling those situations?
Matthew Weier O'Phinney wrote:
-- Ralf Eggert <[EMAIL PROTECTED]> wrote
(on Saturday, 18 October 2008, 11:50 AM +0200):
Hi,
currently the forms and plugins are not handled in the default project
structure. At least I don't see them:
http://framework.zend.com/wiki/x/6KM
I would put them under application/ and application/modules/ respectively:
application/forms/
Actually, it looks like we need to update that document; in the
QuickStart, we defined exactly the above for forms.
application/plugins/
Plugins, on the other hand, we did not define in the structure. Since
plugins are Zend_Controller-specific, it would make sense to put them in
the same hierarchy as action helpers -- so, like this:
application/
controllers/
helpers/
plugins/
and they would be prefixed with the given module name (if not default):
application/
modules/
blog/
controllers/
plugins/
Foo.php - Blog_Controller_Plugin_Foo or Blog_Plugin_Foo
Note that I have two naming conventions there -- we need to finalize a
decision on that. I used the latter convention for the Bug tracker
application I used in the DPC workshop.
application/modules/blog/forms/
application/modules/blog/plugins/
Is this the current best practice?
And how should form and plugin classes be named? And what about form and
plugin loading? Is a Zend_Loader_PluginLoader Object to load forms and
plugins the best practice?
Currently, yes. There is a proposal for a ResourceLoader action helper
currently that would make loading forms and models trivial (and would
use the PluginLoader under the hood). The bug application I referenced
above uses the PluginLoader for these tasks -- and you can see how it
does that in the source for it:
http://github.com/weierophinney/bugapp/tree