megrok.layout --> grokcore.layout and megrok.chameleon --> grokcore.chameleon

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

megrok.layout --> grokcore.layout and megrok.chameleon --> grokcore.chameleon

Jan-Wijbrand Kolman-3
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

_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev
Reply | Threaded
Open this post in threaded view
|

Re: megrok.layout --> grokcore.layout and megrok.chameleon --> grokcore.chameleon

Sylvain Viollon
On Fri, 15 Jul 2011 13:19:59 +0200
Jan-Wijbrand Kolman <[hidden email]> wrote:

> Hi,
>

  Hello,

> 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.
>

  I often use megrok.chameleon.components.ChameleonPageTemplate(OrSo),
  when I have a component and no grokker for it. I would love to have a
  nicer import (like in the package __init__).

  Regards,

  Sylvain,

--
Sylvain Viollon -- Infrae
t +31 10 243 7051 -- http://infrae.com
Hoevestraat 10 3033GC Rotterdam -- The Netherlands
_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev
Reply | Threaded
Open this post in threaded view
|

Re: megrok.layout --> grokcore.layout and megrok.chameleon --> grokcore.chameleon

Christian Klinger
In reply to this post by Jan-Wijbrand Kolman-3
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


_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev
Reply | Threaded
Open this post in threaded view
|

Re: megrok.layout --> grokcore.layout and megrok.chameleon --> grokcore.chameleon

Jan-Wijbrand Kolman-3
In reply to this post by Sylvain Viollon
On 15/07/2011 13:28 , Sylvain Viollon wrote:
>   I often use megrok.chameleon.components.ChameleonPageTemplate(OrSo),
>   when I have a component and no grokker for it. I would love to have a
>   nicer import (like in the package __init__).

Ow, I missed that uses case..!

Let's add that to grok's __init__ indeed.

regards, jw


_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev
Reply | Threaded
Open this post in threaded view
|

Re: megrok.layout --> grokcore.layout and megrok.chameleon --> grokcore.chameleon

Martijn Faassen-2
In reply to this post by Jan-Wijbrand Kolman-3
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

_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev
Reply | Threaded
Open this post in threaded view
|

Re: megrok.layout --> grokcore.layout and megrok.chameleon --> grokcore.chameleon

Jan-Wijbrand Kolman-3
Hi,

On 15/07/2011 13:56 , Martijn Faassen wrote:
> How does this affect the future of grokcore.viewlet? Is this competing
> with grokcore.layout now?

Viewlets do not at all compete with Layout components. Layout components
"compete" with the tradtional ZPT macros. Viewlets and other content
provider can be used perfectly fine when using the Layout and Page
components.

> 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)

The chameleon and layout dependencies now indeed will be pulled in
whether or not you're using them. And indeed we need to figure out a
robust way for these "conditional" imports.

I just thought in this case it was OK not to have to invent that
conditional-import mechanisms before I could add these component that
quite some Grok projects use.

> * 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.

Agreed this would still be (very) useful to work on.

regards, jw

_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev
Reply | Threaded
Open this post in threaded view
|

Re: megrok.layout --> grokcore.layout and megrok.chameleon --> grokcore.chameleon

Martijn Faassen-2
On 07/15/2011 02:22 PM, Jan-Wijbrand Kolman wrote:
> On 15/07/2011 13:56 , Martijn Faassen wrote:
>> How does this affect the future of grokcore.viewlet? Is this competing
>> with grokcore.layout now?
>
> Viewlets do not at all compete with Layout components. Layout components
> "compete" with the tradtional ZPT macros. Viewlets and other content
> provider can be used perfectly fine when using the Layout and Page
> components.

Would be nice to have some sort of guide which points people in the
right direction.

>> 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)
>
> The chameleon and layout dependencies now indeed will be pulled in
> whether or not you're using them. And indeed we need to figure out a
> robust way for these "conditional" imports.
>
> I just thought in this case it was OK not to have to invent that
> conditional-import mechanisms before I could add these component that
> quite some Grok projects use.

Sure, I agree. I think this is progress, and progress is good!

That's why I'm talking about future steps.

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev