[Grok-dev] megrok.chameleon, next steps

Jan-Wijbrand Kolman janwijbrand at gmail.com
Wed May 18 09:26:50 EDT 2011

On 4/18/11 15:42 , Uli Fouquet wrote:
> Jan-Wijbrand Kolman wrote:
>> Ok, it is clear we need to work on megrok.chameleon. I think these are
>> the issues brought up by people in the previous discussion-thread:
>> 1) the dependency on z3c.pt is perceived as unwanted by some people, but
>> at the same time Uli explains[1] why it was added back as dependency.
>> We need to decide to either a) get rid of z3c.pt and move the necessary
>> glue code into megrok.chameleon, or b) to trust the current
>> z3c.pt-rewrite and its maintainer and use it. Votes please.
> My vote is:
> - stick with z3c.pt for next release (except someone is willing to do
>    it right now; I'm far too busy)
> - get rid of it afterwards

I agree with this approach. I'll pursue this route.

>> 2) there's an issue for switching the auto-reloading of changed template
>> files on and off. I understand Chameleon does this by looking for
>> environment variables, however glue layers can signal their own idea of
>> auto-reloading when pagetemplate file objects are instantiated,
>> overriding the environment variable.
>> So, again, we need to decide: a) we use an environment variable specific
>> to chameleon, or b) we provide in the megrok.chameleon glue layer a
>> different way to signal auto-reloading that then can be reused by other
>> component that want different behaviour in development mode[2]. Votes
>> please.
> a) should work already. So it is a decision about b) or not to b) ;)
> I like the way Pyramid does it. Respecting a ``reload_templates`` option
> in deploy.ini/debug.ini sounds nice to me. That would mean to tweak
> grokcore.startup or zope.app.wsgi I assume?
> -0.5 for examining devmode (if that would reintroduce z.a.appsetup).
> Overall +1 for b).

I think we could alter grokcore.startup to pass on a devmode flag -that 
would be set in the debug.ini for example- to the getWSGIApplication() 
call. That way we could stop using the devmode-marker in the zope.conf.

But it all feels rather bolted-on.

I think we could use a modernized way to configure devmode, mailhosts, 
etc. etc., replacing zope.conf's devmode flags and ProductConfiguration. 
This would preferably we defined in the buildout files and applied to 
the debug.ini and deploy.ini files.

regards, jw

More information about the Grok-dev mailing list