[Grok-dev] Layer and skin registrations; possible simplification

Jan-Wijbrand Kolman janwijbrand at gmail.com
Thu Jul 24 05:34:28 EDT 2008


For the applications we're building, we're using layers to quite an 
extent. Every time I try to explain to my co-workers how the layers and 
skins we use are being registered, I get confused looks and frankly I 
get confused explaining it too.

I think the way we register layers and skins can be a bit simpler.

In Grok, it looks like a `grok.Skin` is some kind of component even if 
it really only just triggers the registration of the provision of 
IBrowserSkinType of some layer.

My suggestion:

Let's deprecate the `grok.Skin` "component" and introduce a 
`grok.skin()` directive to be declared on layer components. The 
registration of layers and skins would then look like this::

   class SomeApplicationLayer(grok.IGrokLayer)
     grok.skin('myapp') # activated by ++skin++myapp in the URL

If you need richer layer structure you can of course still create 
hierarchies of layers::

   class AdminLayer(grok.IGrokLayer):

   class CustomAdminLayer(AdminLayer, SomeApplicationLayer):
     grok.skin('custom') # activated by ++skin++custom in the URL

Alternativeley we could use the `grok.name()` directive to set the name 
of the skin::

   class CustomAdminLayer(AdminLayer, SomeApplicationLayer):
     grok.name('custom') # fallback is whatever the name directive does
     grok.skin() # activated by ++skin++custom in the URL

As far as I can see now this could be implemented in a "backwards" 
compatible fashion by properly deprecating the use of `grok.Skin` and by 
introducing the `grok.skin` directive.

Hmm, I do think of one issue right now and that is how to register a 
third-party layer as a skin. You could still subclass that third-party 
layer and set a `grok.skin()` directive on the subclass. Or maybe 
there're other ideas?

Any ideas? Remarks?


More information about the Grok-dev mailing list