[Grok-dev] Introducing Grok / KSS : feedback after 1 week
ree at ree.hu
Mon Aug 25 04:58:04 EDT 2008
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
> 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
Again, I think we should consider solving this in kss.base /
kss.zope then they are in kss.core. There is still a zcml directive that
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
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
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.
More information about the Grok-dev