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 
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://

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.

fn:Dominik Huber
email;internet:[EMAIL PROTECTED]
tel;work:++41 56 534 77 30

Zope3-dev mailing list

Reply via email to