Dylan Jay writes:
> Daniel Nouri wrote:
>> So sorry for hijacking this thread. But I need to explain a bit here;
>> there's two ways to assign templates to your form:
>>
>> - set "template = ViewPageTemplateFile('form.pt')" in your form
>>
>> - register the template via ZCML (as an adapter)
>>
>> Most often you'll find that the first approach works just fine. Your
>> 'form.pt' will typically want to use parts or the whole of the existing
>> plone.z3cform macro, like this:
>>
>> <metal:use use-macro="context/@@ploneform-macros/form" />
>>
>> And that's all there is to it. If you don't specify a template for your
>> form, it will fall back to this anyway.
>>
>> Granted that the way macros are declared and hooked up in Zope 3 /
>> browser views is different. But the template itself ('macros.pt' in
>> this case) looks exactly the same as with macros that live in the skins
>> folder.
>
> It's great that you explained it and I didn't mean to pick on you. But
> my point is that understand z3 code can be really hard by trying to
> read it. at least to the untrained eye. Good documentation is always
> good but are there ways we can make things easier to understand
> without when documentation fails us?
The Zope 3 CA brought us a very modular platform. But now there's the
danger of overdoing it. It's a known problem that the more objects and
indirections are involved, the more complicated it gets to read the
code. Therefore, as a developer, to write good software with the CA,
you'll have to ask yourself constantly: How much modularity do I really
need? Can't I just do with an attribute here, instead of another
lookup? And: How much readability am I sacrificing here?
Then again, having a solid idea of how the CA works in the first place
is a must.
--
Daniel Nouri
http://danielnouri.org
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
