[Grok-dev] Re: Proposal: IGrokDefaultBrowserLayer

[Philipp von Weitershausen]

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

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 
one grok.Layer...

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

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

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