megrok.chameleon and (custom) template namespaces

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

megrok.chameleon and (custom) template namespaces

Jan-Wijbrand Kolman-3
Hi,

Yesterday and today, Jan-Jaap and me migrated most of our codebase to
use megrok.chameleon. However, we do rely on the megrok.chameleon's
trunk now, for this particular reason:

We noticed that the viewlet and the viewletmanager namespaces were
missing from the template context (when rendering a viewletmanager and
viewlets of course).

We started digging and noticed that Grok's idea of template namespaces
was effectively put into the options template namespace by z3c.pt (on
which megrok.chameleon depends). This would include the "custom"
namespace a developer could define through the `def namespace()` method
on views.

Can I ask the current megrok.chameleon "maintainers" (I believe Uli and
Sylvain) 1) to have a look at the patch+test
(http://zope3.pov.lt/trac/changeset/121428/megrok.chameleon) and 2) tell
me if it is release-worthy and 3) grant me pypi-permissions to indeed
make the release?

Thanks in advance!
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.chameleon and (custom) template namespaces

Jan-Jaap Driessen
On 15 April 2011 21:40, Jan-Wijbrand Kolman <[hidden email]> wrote:

> Hi,
>
> Yesterday and today, Jan-Jaap and me migrated most of our codebase to
> use megrok.chameleon. However, we do rely on the megrok.chameleon's
> trunk now, for this particular reason:
>
> We noticed that the viewlet and the viewletmanager namespaces were
> missing from the template context (when rendering a viewletmanager and
> viewlets of course).
>
> We started digging and noticed that Grok's idea of template namespaces
> was effectively put into the options template namespace by z3c.pt (on
> which megrok.chameleon depends). This would include the "custom"
> namespace a developer could define through the `def namespace()` method
> on views.
>
> Can I ask the current megrok.chameleon "maintainers" (I believe Uli and
> Sylvain) 1) to have a look at the patch+test
> (http://zope3.pov.lt/trac/changeset/121428/megrok.chameleon) and 2) tell
> me if it is release-worthy and 3) grant me pypi-permissions to indeed
> make the release?
>
> Thanks in advance!
> regards, jw

Also, as far as I can see, megrok.chameleon currently does not
configure auto-reloading of chameleon templates in development mode.

JW, can we look into the best way to configure this before we make a
new release of megrok.chameleon?


How do you feel about the pylons/pyramid approach of configuring
template reloading? ->

http://docs.pylonsproject.org/projects/pyramid/1.0/narr/templates.html#reload-templates-section

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

Re: megrok.chameleon and (custom) template namespaces

Uli Fouquet
Hi JJ and JW,

Am Freitag, den 15.04.2011, 22:25 +0200 schrieb Jan-Jaap Driessen:

> On 15 April 2011 21:40, Jan-Wijbrand Kolman <[hidden email]> wrote:
> >
> > Yesterday and today, Jan-Jaap and me migrated most of our codebase to
> > use megrok.chameleon. However, we do rely on the megrok.chameleon's
> > trunk now, for this particular reason:
> >
> > We noticed that the viewlet and the viewletmanager namespaces were
> > missing from the template context (when rendering a viewletmanager and
> > viewlets of course).
> >
> > We started digging and noticed that Grok's idea of template namespaces
> > was effectively put into the options template namespace by z3c.pt (on
> > which megrok.chameleon depends). This would include the "custom"
> > namespace a developer could define through the `def namespace()` method
> > on views.
Thanks for fixing that!

> > Can I ask the current megrok.chameleon "maintainers" (I believe Uli and
> > Sylvain) 1) to have a look at the patch+test
> > (http://zope3.pov.lt/trac/changeset/121428/megrok.chameleon)

Looks fine to me.

>  and 2) tell
> > me if it is release-worthy and

I see two blockers for release currently:

  - page reloading should work (at least optional)
  - the docs need a serious upgrade (at least some upgrade guide)


>  3) grant me pypi-permissions to indeed
> > make the release?

Sure, you're both owners now.
 

> > Thanks in advance!
> > regards, jw
>
> Also, as far as I can see, megrok.chameleon currently does not
> configure auto-reloading of chameleon templates in development mode.
>
> JW, can we look into the best way to configure this before we make a
> new release of megrok.chameleon?

Yep, I'd love to see that finished before release too.

>
> How do you feel about the pylons/pyramid approach of configuring
> template reloading? ->
>
> http://docs.pylonsproject.org/projects/pyramid/1.0/narr/templates.html#reload-templates-section

Nice! If we could reproduce it that would be great. Please tell if you
found out more about that, although I'll have a look into this myself.

What do you think about pushing the next release to version number 2.0
(skipping 1.x)? I noticed that also z3c.pt tries to stay in touch with
Chameleon version-number-wise.

Best regards,

--
Uli


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

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: megrok.chameleon and (custom) template namespaces

Souheil CHELFOUH
For the provider: expression, you can copy the code from Dolmen
it's the work i did for chameleon 2.0 on Dolmen, after we forked from grok
http://gitweb.dolmen-project.org/dolmen.tales.git

2011/4/16 Uli Fouquet <[hidden email]>:

> Hi JJ and JW,
>
> Am Freitag, den 15.04.2011, 22:25 +0200 schrieb Jan-Jaap Driessen:
>> On 15 April 2011 21:40, Jan-Wijbrand Kolman <[hidden email]> wrote:
>> >
>> > Yesterday and today, Jan-Jaap and me migrated most of our codebase to
>> > use megrok.chameleon. However, we do rely on the megrok.chameleon's
>> > trunk now, for this particular reason:
>> >
>> > We noticed that the viewlet and the viewletmanager namespaces were
>> > missing from the template context (when rendering a viewletmanager and
>> > viewlets of course).
>> >
>> > We started digging and noticed that Grok's idea of template namespaces
>> > was effectively put into the options template namespace by z3c.pt (on
>> > which megrok.chameleon depends). This would include the "custom"
>> > namespace a developer could define through the `def namespace()` method
>> > on views.
>
> Thanks for fixing that!
>
>> > Can I ask the current megrok.chameleon "maintainers" (I believe Uli and
>> > Sylvain) 1) to have a look at the patch+test
>> > (http://zope3.pov.lt/trac/changeset/121428/megrok.chameleon)
>
> Looks fine to me.
>
>>  and 2) tell
>> > me if it is release-worthy and
>
> I see two blockers for release currently:
>
>  - page reloading should work (at least optional)
>  - the docs need a serious upgrade (at least some upgrade guide)
>
>
>>  3) grant me pypi-permissions to indeed
>> > make the release?
>
> Sure, you're both owners now.
>
>
>> > Thanks in advance!
>> > regards, jw
>>
>> Also, as far as I can see, megrok.chameleon currently does not
>> configure auto-reloading of chameleon templates in development mode.
>>
>> JW, can we look into the best way to configure this before we make a
>> new release of megrok.chameleon?
>
> Yep, I'd love to see that finished before release too.
>
>>
>> How do you feel about the pylons/pyramid approach of configuring
>> template reloading? ->
>>
>> http://docs.pylonsproject.org/projects/pyramid/1.0/narr/templates.html#reload-templates-section
>
> Nice! If we could reproduce it that would be great. Please tell if you
> found out more about that, although I'll have a look into this myself.
>
> What do you think about pushing the next release to version number 2.0
> (skipping 1.x)? I noticed that also z3c.pt tries to stay in touch with
> Chameleon version-number-wise.
>
> Best regards,
>
> --
> Uli
>
>
> _______________________________________________
> Grok-dev mailing list
> [hidden email]
> https://mail.zope.org/mailman/listinfo/grok-dev
>
>
_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev
Reply | Threaded
Open this post in threaded view
|

Re: megrok.chameleon and (custom) template namespaces

Uli Fouquet
Hi Soulheil,

Souheil CHELFOUH wrote:

> For the provider: expression, you can copy the code from Dolmen
> it's the work i did for chameleon 2.0 on Dolmen, after we forked from grok
> http://gitweb.dolmen-project.org/dolmen.tales.git

Thanks a lot, Souheil! I already had a look into dolmen.template and
dolmen.tales. Especially the TALES-expression-plugin-technique via entry
points looks interesting.

But now I already switched to z3c.pt for the base work. z3c.pt registers
almost everything we normally need - including the `provider`
expression. This already worked in megrok.chameleon before JJ and JW
showed up.

I reintroduced z3c.pt for TALES evaluation because the new z3c.pt
version (2.x) is a complete rewrite for Chameleon 2.x (the older
versions raised some problems) and it is maintained by Malthe (the
Chameleon-man), so we can delegate that (sometimes nasty) part to
someone who should really be into this. When Chameleon changes, that's
my hope, also z3c.pt will change and we don't have to do much from our
side except updating the version numbers in gtk.

The overall idea is to have the standard set of TALES expression
registered automatically when you depend on megrok.chameleon. That takes
the burden of identifying possible expressions and registering them for
the own project from users. Just depend on megrok.chameleon and all the
expressions from the common howtos are available.

That, however, does not need to be the end of the road.

Best regards,

--
Uli


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

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: megrok.chameleon and (custom) template namespaces

Jan-Jaap Driessen
In reply to this post by Uli Fouquet
On 16 April 2011 02:15, Uli Fouquet <[hidden email]> wrote:
...
>> How do you feel about the pylons/pyramid approach of configuring
>> template reloading? ->
>>
>> http://docs.pylonsproject.org/projects/pyramid/1.0/narr/templates.html#reload-templates-section
>
> Nice! If we could reproduce it that would be great. Please tell if you
> found out more about that, although I'll have a look into this myself.

In a default grokproject installation (with 'classic'
zope.pagetemplate, no chameleon) I see that page templates are always
reloaded, no matter whether I use the deploy.ini or debug.ini
configuration:

http://zope3.pov.lt/trac/browser/zope.pagetemplate/trunk/src/zope/pagetemplate/pagetemplatefile.py#L91

The developers of z3c.pt must have seen the same issue. The changelog [1] says:

"""Make debug mode setting explicit in a config.py. Currently it is
bound to Python's __debug__, which is False when run with -O and
otherwise True."""

I remember that reloading of page templates was once tied to the
developermode in zope.app.appsetup. Or do I remember incorrectly?

Is it OK to let megrok.chameleon depend on zope.app.appsetup? I have my doubts.


1) http://pypi.python.org/pypi/z3c.pt/2.0-rc1

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

Re: megrok.chameleon and (custom) template namespaces

Jan-Wijbrand Kolman-3
On 4/18/11 11:10 , Jan-Jaap Driessen wrote:

> In a default grokproject installation (with 'classic'
> zope.pagetemplate, no chameleon) I see that page templates are always
> reloaded, no matter whether I use the deploy.ini or debug.ini
> configuration:
>
> http://zope3.pov.lt/trac/browser/zope.pagetemplate/trunk/src/zope/pagetemplate/pagetemplatefile.py#L91
>
> The developers of z3c.pt must have seen the same issue. The changelog [1] says:
>
> """Make debug mode setting explicit in a config.py. Currently it is
> bound to Python's __debug__, which is False when run with -O and
> otherwise True."""
>
> I remember that reloading of page templates was once tied to the
> developermode in zope.app.appsetup. Or do I remember incorrectly?

This is one of these things that is very surprising to me: I always
thought and assumed and apparently never double-checked, that templates
are only reloaded when zope is running in "devmode on".

This is indeed not the case: whenever `__debug__` is True, the template
is reloaded.

Do people actually run their serves with `python -O` (which would make
`__debug__` False, but also would make assert statements to be skipped)?

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.chameleon and (custom) template namespaces

Jan-Wijbrand Kolman-3
In reply to this post by Jan-Jaap Driessen
On 4/15/11 22:25 , Jan-Jaap Driessen wrote:

> Also, as far as I can see, megrok.chameleon currently does not
> configure auto-reloading of chameleon templates in development mode.
>
> JW, can we look into the best way to configure this before we make a
> new release of megrok.chameleon?
>
> How do you feel about the pylons/pyramid approach of configuring
> template reloading? ->
>
> http://docs.pylonsproject.org/projects/pyramid/1.0/narr/templates.html#reload-templates-section

I think I'd rather use the "devmode"-marker instead, not to have
multiple ways for signaling development versus deployment. It is of
course also possible to check both the devmode *and* the env variable.
We could also consider logging the reload-state at startup.

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.chameleon and (custom) template namespaces

Sylvain Viollon
In reply to this post by Jan-Wijbrand Kolman-3
On Mon, 18 Apr 2011 12:01:08 +0200
Jan-Wijbrand Kolman <[hidden email]> wrote:

  Hello,

> This is one of these things that is very surprising to me: I always
> thought and assumed and apparently never double-checked, that
> templates are only reloaded when zope is running in "devmode on".
>
> This is indeed not the case: whenever `__debug__` is True, the
> template is reloaded.
>
> Do people actually run their serves with `python -O` (which would
> make `__debug__` False, but also would make assert statements to be
> skipped)?
>
>

  Honestly, I set CHAMELEON_DEBUG and CHAMELEON_SOURCE when I develop.
  It works, and is good enough I think.

  And as you can guess, I am totally against some Zope 3 specific
  things inside megrok.chameleon.

  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.chameleon and (custom) template namespaces

Sylvain Viollon
In reply to this post by Uli Fouquet
On Sat, 16 Apr 2011 02:15:15 +0200
Uli Fouquet <[hidden email]> wrote:

  Hello,

> > > Can I ask the current megrok.chameleon "maintainers" (I believe
> > > Uli and Sylvain) 1) to have a look at the patch+test
> > > (http://zope3.pov.lt/trac/changeset/121428/megrok.chameleon)
>
> Looks fine to me.
>

  Didn't we drop z3c.pt a while ago ? I am not a big fan of z3c things.
  It always do everything except what you need, is often buggy, and
  brings you thousands of dependencies you don't want.

  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.chameleon and (custom) template namespaces

Jan-Wijbrand Kolman-3
On 4/18/11 12:37 , Sylvain Viollon wrote:

> On Sat, 16 Apr 2011 02:15:15 +0200
> Uli Fouquet<[hidden email]>  wrote:
>
>>>> Can I ask the current megrok.chameleon "maintainers" (I believe
>>>> Uli and Sylvain) 1) to have a look at the patch+test
>>>> (http://zope3.pov.lt/trac/changeset/121428/megrok.chameleon)
>>
>> Looks fine to me.
>
>    Didn't we drop z3c.pt a while ago ? I am not a big fan of z3c things.
>    It always do everything except what you need, is often buggy, and
>    brings you thousands of dependencies you don't want.

So, instead we use what?
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.chameleon and (custom) template namespaces

Jan-Wijbrand Kolman-3
In reply to this post by Sylvain Viollon
On 4/18/11 12:35 , Sylvain Viollon wrote:

> On Mon, 18 Apr 2011 12:01:08 +0200
> Jan-Wijbrand Kolman<[hidden email]>  wrote:
>
>    Hello,
>
>> This is one of these things that is very surprising to me: I always
>> thought and assumed and apparently never double-checked, that
>> templates are only reloaded when zope is running in "devmode on".
>>
>> This is indeed not the case: whenever `__debug__` is True, the
>> template is reloaded.
>>
>> Do people actually run their serves with `python -O` (which would
>> make `__debug__` False, but also would make assert statements to be
>> skipped)?
>>
>>
>
>    Honestly, I set CHAMELEON_DEBUG and CHAMELEON_SOURCE when I develop.
>    It works, and is good enough I think.
>
>    And as you can guess, I am totally against some Zope 3 specific
>    things inside megrok.chameleon.

Apart from the "zope 3 specificness" in this discussion:

I really do not like to have multiple flags and markers and environment
variables for all kinds of configurations if we can have one: a flag
that says whether the app is running in development-mode or not.

regards, jw

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