-- Steven Szymczak <[EMAIL PROTECTED]> wrote
(on Saturday, 18 October 2008, 06:09 PM +0100):
> 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?
Put them in your library code.
application/
library/
<your_prefix_here>/
Controller/
Action/
Helper/
Plugin/
Form/
Decorator/
Element/
etc.
Alternately, another approach I've seen is that anything global to the
application goes in your default module. However, if you feel it is
functionality that will be used cross-module, then typically this can be
considered library code, and should go into your custom library
extensions.
> 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
>>
>
--
Matthew Weier O'Phinney
Software Architect | [EMAIL PROTECTED]
Zend Framework | http://framework.zend.com/
