[Grok-dev] Re: grok.layer branch

[Philipp von Weitershausen]

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