[Grok-dev] Layer and skin registrations; possible simplification
Jan-Wijbrand Kolman
janwijbrand at gmail.com
Thu Jul 24 05:34:28 EDT 2008
Hi,
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):
pass
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?
regards,
jw
More information about the Grok-dev
mailing list