Tonico Strasser wrote:
>>> In CMF things are very easy to understand, because a layer is simply a
>>> folder. I can explain that in five minutes to a template programmer.
>> Why does the template programmer need to know about layers?
> Because in CMF, if you want to customize or create a skin, you need to
> know about the so called "layers".
But we aren't in the CMF :).
Seriously, you are right about the fact that you need to know about
layers when you want to work with skins. Let's just be clear on the
actors' names: template programmer isn't necessarily the same as a skin
A template author just writes a page template and isn't necessarily
concerned how and where it is going to be registered. Most of the time,
it is fine to register browser pages (incl. template-based ones) for the
default layer. That is a huge difference to the CMF where everything
lives in a very specific layer (which I find annoying and complicated)
and that layer has to be registered in a skin (which most CMF product's
Install.py will automatically do...).
Now, the skin customizer might write some templates to actually perform
some customization first, but his job description really is about
setting up the layer(s) and registering one of them as a skin. For that
you need to know about layers, yes. But not when you only want to author
>>> Maybe this sounds a bit NAIVE, but would it be possible to make it like
>>> in CMF?
>> The CMF approach is very limiting. The fact that a layer equals a
>> physical location (a folder) led to every CMF-based product coming up
>> with its own layer -- because there is no way to put stuff into existing
>> layers, not even the default layer. Layers as they are in Zope 3 have
>> stopped this senseless layer proliferation.
>> I find Zope 3's approach much simpler and much easier to explain than
>> the CMF's approach. In Zope 3 (especially with my proposed changes in
>> place), a layer is simply a label (read: marker interface) on the
>> request. When we now look up pages and resources (e.g. images), we take
>> the request into account and therefore inevitably that label. We will
>> only find pages and resources associated (read: registered) for this
>> label. Good news is that any page or resource can be associated for this
>> label, we just have to remember to do that in their ZCML directive.
>> See, now I even explained this to a "template programmer", though I
>> don't think he'd care.
> Maybe I mean something different. I just want a folder in which I can
> drop all the files I want to customize (I love to customize), without
> registering something.
That's not how it works in Zope 3, at least not right now and not by
default. My proposal doesn't isn't addressing this.
Shane has expressed an interesting idea that goes into the "I just drop
my stuff in here" direction, but I'm frankly missing some important
points in this idea yet. It might be interesting to develop it further,
though. For now, however, we have to explicitly register everything. I
consider that a good thing.
> Is this a layer?
A layer is a marker interface on the request (Zope 3 definition).
> You're right, I don't care :)
I think you don't care for the wrong reasons. You want your CMF
experience duplicated. Perhaps you're not as bothered as I was with the
CMF's limitations, but it sured annoyed me as hell having to create a
new layer for every product I wrote for CMF.
Zope3-dev mailing list