megrok.chameleon, next steps

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

megrok.chameleon, next steps

Jan-Wijbrand Kolman-3
Hi,

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.

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.

regards, jw

[1] http://permalink.gmane.org/gmane.comp.web.zope.grok.devel/11086
[2] for example by making use of Grok's (Zope's) devmode flag.

_______________________________________________
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, next steps

Uli Fouquet
Hi JW,

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

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

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, next steps

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







_______________________________________________
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, next steps

Jan-Wijbrand Kolman-3
On 5/18/11 15:26 , Jan-Wijbrand Kolman wrote:

> 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

Uli, quick question:

Part of the overhaul in megrok.chameleon was the removal of
genshi-template components from megrok.chameleon. Could you perhaps
elaborate a little on this decision? Preferably in the CHANGES.txt of
the megrok.chameleon package so that this information will be reflected
on the pypi.

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, next steps

Souheil CHELFOUH
genshi is no longer part of the base Chameleon2 engines.
That's the only reason i suspect

2011/5/19 Jan-Wijbrand Kolman <[hidden email]>:

> On 5/18/11 15:26 , Jan-Wijbrand Kolman wrote:
>> 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
>
> Uli, quick question:
>
> Part of the overhaul in megrok.chameleon was the removal of
> genshi-template components from megrok.chameleon. Could you perhaps
> elaborate a little on this decision? Preferably in the CHANGES.txt of
> the megrok.chameleon package so that this information will be reflected
> on the pypi.
>
> regards, jw
>
> _______________________________________________
> 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, next steps

Jan-Wijbrand Kolman-3
On 5/19/11 12:38 , Souheil CHELFOUH wrote:
> genshi is no longer part of the base Chameleon2 engines.
> That's the only reason i suspect

Aha! Right, I see. Genshi has left the Chameleon > 2.0 building.

(As an aside: personally I'm not using Genshi, but it might be nice if
the reasons for not including Genshi in Chameleon anymore, would have
been documented somewhere, but I cannot find it.)

Anyway, I amended the changelog of megrok.chameleon accordingly and I
think I could release megrok.chamelein 1.0-rc1 now.

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, next steps

Uli Fouquet
Hi JW,

sorry, I replied before, but only to Souheil.

Am Donnerstag, den 19.05.2011, 15:22 +0200 schrieb Jan-Wijbrand Kolman:
> On 5/19/11 12:38 , Souheil CHELFOUH wrote:
> > genshi is no longer part of the base Chameleon2 engines.
> > That's the only reason i suspect
>
> Aha! Right, I see. Genshi has left the Chameleon > 2.0 building.

Yep that was the main reason. Beside this there is a megrok.genshi
package which sounds more like the correct place for Genshi support.

For megrok.chameleon I'd only want to support what Chameleon itself
supports (even if it is changing all the time).

> (As an aside: personally I'm not using Genshi, but it might be nice if
> the reasons for not including Genshi in Chameleon anymore, would have
> been documented somewhere, but I cannot find it.)

Sorry for the bad docs. That was due to lack of time. At least all
mentions of Genshi in the docs vanished (hopefully).

> Anyway, I amended the changelog of megrok.chameleon accordingly and I
> think I could release megrok.chamelein 1.0-rc1 now.

Sounds great, thank you very much!

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, next steps

Jan-Wijbrand Kolman-3
On 5/19/11 16:01 , Uli Fouquet wrote:

> Am Donnerstag, den 19.05.2011, 15:22 +0200 schrieb Jan-Wijbrand Kolman:
>> On 5/19/11 12:38 , Souheil CHELFOUH wrote:
>>> genshi is no longer part of the base Chameleon2 engines.
>>> That's the only reason i suspect
>>
>> Aha! Right, I see. Genshi has left the Chameleon>  2.0 building.
>
> Yep that was the main reason. Beside this there is a megrok.genshi
> package which sounds more like the correct place for Genshi support.
>
> For megrok.chameleon I'd only want to support what Chameleon itself
> supports (even if it is changing all the time).
>
>> (As an aside: personally I'm not using Genshi, but it might be nice if
>> the reasons for not including Genshi in Chameleon anymore, would have
>> been documented somewhere, but I cannot find it.)
>
> Sorry for the bad docs. That was due to lack of time. At least all
> mentions of Genshi in the docs vanished (hopefully).

I removed some remaining references.

Anyway, I didn't mean that *you* should've provided more explanations
for the gone Genshi support from Chameleon. What I meant is that the
Chameleon documentation itself hardly elaborates on this choice. It
would've been nice to be able to point to an explanation from our docs.

But again, I myself like the page template language still very very much
and do not use much else - so I'm very happy with the megrok.chameleon
glue :-)

>> Anyway, I amended the changelog of megrok.chameleon accordingly and I
>> think I could release megrok.chamelein 1.0-rc1 now.
>
> Sounds great, thank you very much!

I released 1.0-rc1 indeed. A "proper" 1.0 will be done once the
Chameleon and z3c.pt package have released final versions too. And in
the meantime we can incorporate feedback we might get for the
megrok.chameleon package.

regards, jw

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