[Grok-dev] Re: Proposal: IGrokDefaultBrowserLayer
kevin at mcweekly.com
Mon Apr 16 16:55:53 EDT 2007
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...
pass # complete skin with static/ and grok layer
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.
>> * Allows seperation of static/ directory, useful for custom skinning
>> * Eliminates the Rotterdam ZMI , which has been mentioned previously
>> on the list
>> * Worksaround the @@contents bug (I think)
> Yup, I've been thinking about the same thing.
> I'm certainly in favour or disabling all non-Grok views when in "Grok
> mode". We need to define what "Grok mode" means:
> 1.) An easy definition (and compatible with our current understanding
> of Grok view security) would be "Grok's publication is enabled" (IOW,
> the 'grok' package is present and being loaded).
> 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? Today while working on
non-grok code I was sorely missing grok.View :)
> 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.
> With definition #2 of "Grok mode", we could also think about
> changing the view security model to only come into effect when having
> traversed over this special object.
More information about the Grok-dev