[Grok-dev] megrok.layout --> grokcore.layout and megrok.chameleon --> grokcore.chameleon

Martijn Faassen faassen at startifact.com
Fri Jul 15 07:56:31 EDT 2011


On 07/15/2011 01:19 PM, Jan-Wijbrand Kolman wrote:

> A while ago I suggested to "promote" megrok.layout and megrok.chameleon
> into the grokcore.* namespace and make them "First Class Cavemen".

I'm all right with that, though I must say that I don't use either 
layout or chameleon in my projects of the last year. That's because I've 
been using Grok as a JSON publication framework and not been relying on 
server-side templating at all.

So if they're grokcore.* I'd rather have a way to *not* pull them in, as 
that's code I'm not using. Though if we can drop the old ZPT support and 
make Chameleon the new thing that'd be fine with me.

I realize we already depended on megrok.layout for the UI.

How does this affect the future of grokcore.viewlet? Is this competing 
with grokcore.layout now?

I think for future steps we need to make progress on two topics we 
identified during the last sprint:

* a grok core that is okay with dropping selective dependencies 
(conditionally importing them for convenience reasons)

* a grok core that doesn't depend on the Grok UI, and instead just has 
one application installed as the top level. It'd be good to make this 
work for both ZODB apps as well as ZODB-less apps.

This way we can have an "all-in" Grok that is good for "traditional" 
zope applications, but also have the option of a more "light weight" 
Grok that drops things like the ZODB, grokcore.layout, grokcore.viewlet, 



More information about the Grok-dev mailing list