[Grok-dev] Re: Layer and skin registrations; possible simplification

[Jan-Wijbrand Kolman]

Thanks for your feedback.

Philipp von Weitershausen wrote:
snip
> Why is there IGrokLayer? Let's deprecate that as well. As far as I can 
> tell, it bears no use whatsoever. If people are worried about having to 
> import a base interface, then let's expose IBrowserRequest from grok. 
> Because that's what you should use to base layers and skins on anyways.

I agree. I just wanted to focus on one specific issue for now :) As far 
as I can see now, the IGrokLayer is just way of communicating intent.

>>   class CustomAdminLayer(AdminLayer, SomeApplicationLayer):
>>     grok.skin('custom') # activated by ++skin++custom in the URL
> 
> That looks good to me. Note that grok.skin() is a directive that has to 
> work on interfaces (since layers and skins are interfaces). This isn't 
> trivial because directives generally want to store attributes on the 
> scope they're used at. Interfaces won't allow that (you'll get an 
> ominous "Concrete attribute" error).
> 
> However, interfaces allow tagged values (sort of like annotations). 
> We'll have to make the grok.skin's storage part use tagged values. 
> plone.supermodel already implements such a storage that we might be able 
> to nick ;). See FieldsetStorage in 
> https://svn.plone.org/svn/plone/plone.supermodel/trunk/plone/supermodel/directives.py. 

Ah, thanks for the hint. I did realise I needed to something special 
here, but I hadn't looked into the details yet.

>> 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
> 
> -1
> 
> grok.name won't work on interfaces (see above for reason) and trying to 
> make it would complicate its implementation tremendously.

Understood.

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

I'll start on this then.


regards,
jw