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
something_else
cmf_default
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):
pass
<interface interface="...IMyDefaultSkin"
type="zope.publisher.interfaces.browser.IBrowserSkinType"
name="MySkin"
/>
<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
Products.CMFDefault.skin 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
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
_______________________________________________
Zope-CMF maillist - [email protected]
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
