Philipp von Weitershausen wrote:
Thanks for the input so far, please revise it and let me know if
you see any other issues.
+1 I like it. Thank you!
Your connotation assertion here is incorrect. The default layer stands for:
"If the browser directive did not specify a layer, use the default layer." By
default, the Basic and thus Rotterdam skin incorporate that layer, but others
like Dominik and Garrett do not want to include that layer.
Right. I wonder if we should make the 'layer' argument mandatory then. Right
now we have
the connotation "You can leave the layer argument out in which case Zope will
use some
arbitrary layer that might or might not be in your skins and is boldly called
'default'."
I find the current optional layer argument ok. In our current pratice we
allways use the default for the basic or general views of a package.
This offers a simple way to configure a
out-of-the-box-general-purpose-administration-skin like the Rotterdam
whitout the drawback that such a general skin should have to know a
dedicated layer itself. If we provide other dedicated layers we always
do additional registrations to those layers.
A fairly usefull pattern that becomes manifest in our pratice:
1. Layers for one or more features belonging together. For such a unit
we define three different layers that
covers the following aspects of an application:
-> minimal_feature layer: Invisible functionality like traverser that
should be there even if there is no ui
-> user_feature layer: All views for general end-user usage
-> admin_featur layer: Views for administration purposes.
(One example for a minimal layer tiks
svn://svn.tiks.org/repos/Tiks/trunk/src/tiks/skins/minimal)
2. Those feature layers are used to compose the a custom skin afterwards.
-> pretty modular and clearly arranged whitout beeing to granular.
3. Because we still register to the default layer a general zmi like the
rotterdam skin can be used too.
->this is cool, because everybody can use its favority general-purpose
skin and it doesn't hurts his
brain to guess where he should configure something (compared to plone in
hybrid zope2/plone applications)
Maybe we should introduce a minimal_zope_core and other important layers
which might simplify such application for all parties.
Regards,
Dominik
begin:vcard
fn:Dominik Huber
n:Huber;Dominik
email;internet:[EMAIL PROTECTED]
tel;work:++41 56 534 77 30
x-mozilla-html:FALSE
version:2.1
end:vcard
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
