Am 28.05.2008 um 13:02 schrieb Philipp von Weitershausen:

Views don't "use" layers. You apply a skin layer to the request, and depending on whether the view was registered for this skin layer or any of the layers that are contained in that skin layer, the view will be found.

Thanks, that's the explanation I was missing - I hope I'm not the only one who doesn't quite understand what is adapting what when a view is called. 8-)

The effect being much the same as a customised view in a CMF layer:
higher up the chain takes precedence.

Zope 3 layers and skins work exactly like that.

But it seems that this is not the case: unless it is set otherwise Zope will use the default skin.

Sure, but that's just like in the CMF where you tell the portal_skins tool which skin is the default.

Is it possible to get individual views to use different skins without using ++skin++ in the URL?

That doesn't make any sense to me and it's not how the CMF works either. In the CMF you may put different views in different skin layers (i.e. folders), but then you always combine them to a skin (in "Properties" page of the portal_skins tool where you enter a list of folders that make up the skin). For instance, you may have the following skin definition there:

Default = custom

This is very similar to Zope 3, except that we now have interfaces, e.g. ICMFDefaultSkin, ISomethingElse and IMyCustomLayer. You'd now register views for those layer interfaces (probably just for IMyCustomLayer) and then combine those layer interfaces in a skin interface, which is then given a name using the <interface /> directive and then registered as the default skin:

class IMySkin(ICustom, ISomethingElse, ICMFDefaultSkin):

<interface interface="...IMyDefaultSkin"

<browser:defaultSkin name="MySkin" />

Okay, this is starting to make sense. Layers and skins are confusing especially as they are all just interfaces! :-O When does the skin name get used apart from in ++skin++ urls? Views are still registered to layers, ie. interfaces, aren't they?

What I had been expecting to work, but which I think I now understand why it wouldn't, was the ability to add a layer for something like an "administration" layer which would call a version of standard_macros specific to that layer. I was hoping to be able to change this simply in ZCML rather than in the templates, ie. configure the views I want to use a different "skin". Instead, it seems, I need to write and register my own macros and change those templates that need to use them. Not sure whether this is entirely the right way to go about this, as opposed to using a viewlet to do it but as least I've got it to work.

Regarding CMFDefault - all views are registered explicitly for ICMFDefaultSkin but I think this isn't necessary as this is configured as the default skin.

No, it *is* necessary, because the default skin can always change. In fact, nearly every application (in the Zope 3 world) sets the default skin (otherwise you'd need those hideous ++skin++ things in all URLs).

Also, by explicitly putting all views on the ICMFDefaultSkin layer, those views are only there if your skin interface inherits from ICMFDefaultSkin. Which means you can easily "switch off" those CMF views by not including ICMFDefaultSkin. For some people this is an important use case.
Wouldn't that raise an error on startup if ICMFDefaultSkin isn't found?

Uh, it's an interface... how can it not be found?

I wasn't sure how you meant "not including ICMFDefaultSkin" and assumed you might mean leave out the configure.zcml from rather than not inheriting from it.

Or how do you "not include" ICMFDefaultSkin? Using overrides?

By having your skin interface not inherit from ICMFDefaultSkin, just like in the CMF where you would remove the cmf_default layer from the skin definition if you didn't want to have the views from cmf_default available.

PS: in your book the appendix to ZCML browser:defaultSkin says "see browser:skin". This has been deprecated, I think.

Ah, thank you!

You're welcome. For the fourth edition, and I hope there will be one, it might be an idea to add a couple of paragraphs from above to clarify customisation by adding a layer, ie. where world_cookery inherits from Rotterdam and where it differs.

Charlie Clark
Helmholtzstr. 20
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226

Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to