[Grok-dev] Re: Proposal: IGrokDefaultBrowserLayer
Philipp von Weitershausen
philipp at weitershausen.de
Mon Apr 16 17:05:14 EDT 2007
Kevin Smith wrote:
> Philipp von Weitershausen wrote:
>> Kevin Smith wrote:
>>> One hitch to implementing skins and layer is that static/ is hard
>>> coded to IDefaultBrowserLayer. I would like to propose
>>> IGrokDefaultBrowser layer to override IDefaultBrowserLayer as the
>>> default skin.
>>> To be used like ...
>>> class StaticLayer(grok.Layer):
>>> pass # this is what static/ is bound to
>>> class GrokLayer(grok.Layer):
>>> pass # all other grok views go here
>>> class IGrokDefaultBrowserLayer(StaticLayer, GrokLayer):
>>> pass # combined skin definition
>> To me this seems backwards. I would think that grok.Layer would
>> automatically include StaticLayer and GrokLayer.
> Thanks for your feedback. I see what your saying, so for my use case...
> class AdminSkin(grok.Layer):
> pass # complete skin with static/ and grok layer
> grok.define_skin('Admin', AdminSkin)
> Then to create a public UI that didn't include the static/ files
> available to the admin UI, it
> would need to be put in a different package.
> class PublicSkin(grok.Layer):
> grok.define_skin('Public', PublicSkin)
I didn't pay enough attention to that StaticLayer thing earlier. What
kind of use case are you trying to address with it? You do realize that
*all* static directory resources would be registered for this layer. If
I understand correctly, you want to use it as an overrides mechanism.
That won't work.
We *should* probably make it possible to define which layer the static
directory resource will be registered for. That won't require inventing
a separate StaticLayer, though. In fact, so far I only see a need for
>> 2.) Another definition that would allow Grok-based views to work
>> within standard Zope applications would be "Once we have traversed
>> over a special object (e.g. grok.Model)".
> This is very appealing. Would a mixin work?
Ick, mixin. We would certainly use an interface.
This approach isn't as easy as it sounds, I suspect. I was mostly waving
>> For definition #1 of "Grok mode", we would require that all skins
>> (incl. the default skin) inherit from grok.Layer (otherwise Grok views
>> won't appear). For definition #2 of "Grok mode", we could assign this
>> layer to the request when traversing that special object (via
>> One nice side-effect of the first and easy definition of "Grok mode"
>> would be that Rotterdam and all those other views would simply be
>> gone. That can be seen as a disadvantage, obviously ("hey, where's my
>> foolder listing view?").
> The grok admin could be beefed up a bit just for navigating the content
> tree. It barely does that currently.
That's indeed the plan. It's on Uli's plate, one of our two GSoC
students for Grok.
http://worldcookery.com -- Professional Zope documentation and training
More information about the Grok-dev