[Grok-dev] Re: Proposal: IGrokDefaultBrowserLayer

[Kevin Smith]

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...

myapp/app.py
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.

myapp/public/app.py
class PublicSkin(grok.Layer):
    pass

grok.define_skin('Public', PublicSkin)

>> * 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 
> subscriber).
>
> 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.
>
>