Am 28.05.2008 um 15:44 schrieb Philipp von Weitershausen:
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-)
Um, this is explained in detail in my book. Views are always looked
up like this:
getMultiAdapter( (context, request), name="foo.html" )
(whitespace added for clarification.)
So by applying marker interfaces to the request, we can change the
output of that adaption. See pages 168-169 in my book.
I understand the theory. I know that views are adapters but as this is
still something I'm not that familiar with and particularly as I don't
write a lot of code using them, it's easy to forget what's exactly
Okay, this is starting to make sense. Layers and skins are
confusing especially as they are all just interfaces!
class IMySkin(ICustom, ISomethingElse, ICMFDefaultSkin):
<browser:defaultSkin name="MySkin" />
That's what's so easy about them!
Agreed but it does make the naming interface/layer/skin entirely a
matter of convention. Great once you're used to it.
:-O When does the skin name get used apart from in ++skin++ urls?
Wherever you'd like to use it. Perhaps you'd like to show a list of
available skins to the user so that s/he can choose one.
Okay - otherwise little relevance for programming?
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.
I'm not quite sure I'm following you here. Often skins mostly
contain custom macros, meaning all views are registered for some
default layer (e.g. IDefaultBrowserLayer) and they look up macros
using context/@@standard_macros. Then it's up to the specific skin
to provide a standard_macros view. This is the one that defines the
look and feel of the site and therefore changes from skin to skin.
I understand this now. My current use case is
This is exactly what my book explains and does (see Exapmles 10.3.2
and 30.3.3)! Forgive my bluntness, but it's hard to believe at this
point you've read it...
Reading is not necessarily understanding! This is no criticism of the
book which, by the way, I think is exceptionally well written. But as
with so many things, some things only click into place when you
actually work with them and some things only make sense when you've
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.
The IWorldcookerySkin interface doesn't inherit from Rotterdam. And
to be honest, I wouldn't know what else to write. I even have a
"Flashback" box that compares Zope 3 style layers to CMF layers and
skins on page 173. And what I've written in the two previous emails
were mostly rephrased passages from my book anyway.
Well, maybe it's an opportunity for me! ;-)
Thank you very much for taking the time to explain this in greater
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests