[Grok-dev] Re: grok.layer branch
Philipp von Weitershausen
philipp at weitershausen.de
Wed Apr 18 14:35:52 EDT 2007
Kevin Smith wrote:
> I just checked in tests to ftests/static/simple.py that show that the
> 'static/' resource isn't available to custom layers unless the custom
> layers are derived from IDefaultBrowserLayer.
>
> IMO this creates an undesired side-effect of inheriting the Rotterdam
> skin and so this dovetails to the IGrokDefaultBrowserLayer proposal.
IDefaultBrowserLayer doesn't really imply the Rotterdam skin. What it
really does imply are all those other non-Grok views that we want to get
rid of.
> Although my original proposal created a special layer just for the
> static resources, it was shown that it was unecessary and simply
> creating the IGrokDefaultBrowserLayer was enough but would make
> Rotterdam and the folder listing view unavailable.
Even just making grok.Layer is enough. I still don't see the use for
IGrokDefaultBrowserLayer if we wanted to make Rotterdam and all the
other views disappear (see below).
> So my question, can the skin layer branch be deployed as is with the
> caveat that IDefaultBrowserLayer needs to be subclassed to access static
> resources, or does the IGrokDefaultBrowserLayer proposal need to be
> finalized first.
I wouldn't mind doing the latter right away. It seems like a logical step.
As I've commented earlier and above, I don't see the need for
IGrokDefaultBrowserLayer. grok.Layer will simply be our "default layer".
Unless you specify grok.layer() in your view class, everything will be
registered for grok.Layer, including the static directory resource.
I also have a few more comments on your branch, after thinking some more
about this matter:
grok.register_skin API
======================
While looking at tests, I found the spelling of grok.register_skin()
awkward. The current spelling is grok.register_skin(name, layer). Most
registrations functions that we have in Zope 3 and Grok first state the
object that's to be registered, then registration details like the name.
I suggest the following API: grok.register_skin(layer, name=None). If
the 'name' parameter is omitted, layer.__name__ is taken. That way I
would do::
class Dresden(grok.Layer):
"""The Dresden skin"""
grok.register_skin(Dresden)
and access it using ++skin++Dresden.
Default skin
============
We need a grokkish way of defining the default skin. I suggest something
like this:
grok.default_skin(Dresden)
grok.default_skin('Dresden')
IOW, you can either pass in the layer interface or the name.
Thanks for sticking with this so far, this turns out to be a bit more
work than expected, but I think in the end we've come to understand the
issues better. I really think we're on the right track and I'm looking
forward to seeing this out there.
Incidentally, this brings us closer to the features planned for 1.0!
--
http://worldcookery.com -- Professional Zope documentation and training
More information about the Grok-dev
mailing list