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

[Christian Klinger]

Hi,

perfect, very cool to have these addons now per default on board.

Thanks for your work.

- Christian

> Hi,
>
> A while ago I suggested to "promote" megrok.layout and megrok.chameleon
> into the grokcore.* namespace and make them "First Class Cavemen".
>
> This week Jan-Jaap, Sylvain and me worked on this rename, which was
> essentially mechanical work - even though Jan-Jaap was able to clean-up
> megrok^H^H^H^H^Hgrokcore.chameleon even further, freeing it from
> zope.app. cruft that was left behind.
>
> As a result we do now have grokcore.layout and grokcore.chameleon. The
> grok package depends on these two now and exposes the components of
> grokcore.layout (and at the same mixes in application_url() and flash()
> methods) for Layout, Page, FormPage, AddFormPage, EditFormPage,
> DisplayFormPage. There's also ExceptionPage, NotFoundPage and
> UnauthorizedPage.
>
> Even though grokcore.chameleon does not have "exposable" components per
> se, the grok package includes the configure.zcml of grokcore.chameleon
> which means, templates with a *.cpt filename extension will be processed
> by the Chameleon template engine.
>
> Yesterday we added grokcore.layout and grokcore.chameleon to the Grok
> Toolkit. We had to update grokui.base and grokui.admin a bit as they
> used to use megrok.layout - and obviously they now use the components
> exposed by grok.
>
> The grok, grokcore.layout, grokcore.chameleon and grokui.* packages all
> have been released and can be used in your projects. I think it is time
> for another Grok (you know, the toolkit thingy) release too, but I do
> not have the time Right Now.
>
> And how do we signal the "deprecated-ness" of megrok.layout and
> megrok.chameleon? Best idea I could come up with, is to add a big fat
> warning in the readmes and or changelogs for these packages and update
> the pypi pages with these warnings.
>
> regards, jw