[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
Hey,
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,
etc.
Regards,
Martijn
More information about the Grok-dev
mailing list