[Grok-dev] Introducing Grok / KSS : feedback after 1 week

[Balazs Ree]

On Mon, 25 Aug 2008 10:30:16 +0200, Godefroid Chapelle wrote:

> Balazs Ree wrote:
>> Hi Sebastien,
>> 
>>> Sebastien Douche wrote:
>>>> Hi there,
>>>> A small post after familiarized Grok (+ KSS) in my company, with
>>>> Godefroid (__gotcha) as Guest Star.
>>>>
>>>> + Using Grok is easy.
>>>>
>>>> + Using KSS is very easy.
>> 
>> Thank You. We are happy to see that our work brings value to others.
>> 
>> 
>>>> - Lack of KSS support for Zope 3 application (not Plone).
>>> Could you elaborate? Perhaps Godefroid can also describe what he
>>> thinks the plan should be.
> 
> I am afraid Sebastien used a very wide statement for small problems.
> 
> There are two issues concerned by his statement :
> 
> 1) Some people claim that kss.core is not Python 2.5 compatible (I did
> not try myself). Even if this is true, I think it is not a big deal at
> all until we get an official statement from the community that Z3 is
> supported over 2.5. Anyway, I suppose it will be very easy to fix.


I agree. We should also consider that we plan to make kss.base take off, 
which, being a python-only library, probably supports Python 2.5 
already.


> 2) KSS could play a better game in skin/layer setup.  Currently, KSS
> views are defined in the default layer. This implies that someone that
> does not want to use the default layer has to register all KSS views
> again in his own layer/skin. (This is also a small issue.)
> 
> We could fix this by putting all KSS views in its own layer : this would
> allow to integrate KSS layer separately from the default layer.
> 
> However, this would imply that a custom skin would be obligatory for any
> application using KSS.
> 
> This would then imply that the given layer should be registered for
> Plone (possible since plone.browserlayer in 3.1).
> 
> I am not sure which constraint is worse : being forced to use default
> layer or being forced to create a custom skin.

Thank you. I am not very experienced in layers in practice, so maybe what 
I write below is wrong, but this is my first idea for approaching this 
problem.

Again, I think we should consider solving this in kss.base / 
kss.zope. The javascript resources are defined slightly differently in 
kss.zope then they are in kss.core. There is still a zcml directive that 
defines the contatenated javascript resource, but it will no longer need 
the list of all javascript files as input, since this information will 
come from the kss plugin registry (existing on plain python level). Which 
means it's easy to use this directive from zcml, which was not the case 
with kss.core.

So, we could add a layer attribute to this directive. Then, kss.zope can 
keep on defining the resource for the default layer. However anyone that 
wants to have a custom layer, could simply define the kss javascript 
resource for the desired layer, from zcml. This could work in Zope. Grok 
then, can decide, what approach it takes to provide the Grok Way of 
handling the same resource for custom layers.
 

Best wishes,

-- 
Balazs Ree