[Grok-dev] groktoolkit: z3c.pt and chameleon issues

Uli Fouquet uli at gnufix.de
Mon Mar 1 10:42:43 EST 2010


Hi Sylvain,

Sylvain Viollon wrote:
> On Thu, 25 Feb 2010 00:08:43 +0100
> Uli Fouquet <uli at gnufix.de> wrote:

> 
> > Souheil CHELFOUH wrote:
> > > I'd rather dump the dependency as well
> > > 
> > > 2010/2/24 Martijn Faassen <faassen at startifact.com>:
> > > >
> > > > In principle I'm in favor of dumping this dependency if indeed
> > > > it's so lightweight. Aren't we doing more though? What about,
> > > > say, i18n integration?
> > 
> > I am relatively sure, that 'exists' would really be the only thing
> > affected by removing z3c.pt. 
> > 
> 
>   I like to dump things as well.

Do you have any suggestions, what to drop?

> > i18n is in principle also supported by Chameleon, but not specifically
> > supported in megrok.chameleon. You can use translations as shown by
> > Sylvain before: simply define a ``namespace`` method in your i18n-ed
> > view returning something like {'translation-language': 'de'}. This is
> > certainly a field of possible improvements for megrok.chameleon, but
> > I'd tend to concentrate on Chameleon-geared support (i.e. all support
> > should come via Chameleon, not any z3c helper package if avoidable).
> > 
> 
>   I think, if we set chameleon as default, having the default grok View
>   adding this in the default namespace is an interesting solution: I add
>   many projects in which I add to use translations that were not set
>   using the language of the browser. Having just to set that value in
>   the namespace in order to choose the translation target language is
>   quite handy.
> 
>   (It's target_language btw).

Yes, I know that stuff. I am personally open to both solutions, setting
no language in default namespace at all or picking the browser-requested
one. It depends on what developers find more handy. Your statement is
clear in that respect :-)

For the next megrok.chameleon release I will at least add some examples
about using Chameleon-powered i18n in templates, includung
``target_language``, of course.

>   Are you sure that the provider expression is not defined as well in
>   z3c.pt ? I am confident it used to be, at least not that long ago...

No, quite the contrary: I am absolutely sure now, that the ``provider``
expression _is_ provided by z3c.pt, together with ``exists``, ``not``
and maybe other things. That's what I already admitted in my last post
in this thread ;-)

Right now this stuff is too much to write a replacement in
megrok.chameleon. Especially, because there is not much to drop. Even if
we drop support for ``exists``, it will not mean much less code to port,
because the more complicated things like general expression parsing and
the like still had to be replaced (mostly copied) anyway. Therefore, I
think, it is more efficient to use z3c.pt as it is.

If, however, we'd drop also support for ``path`` expressions (which
would possibly reduce the amount of code to port considerably), we'd
lose a really handy tool allowing people to switch from path-expressions
to pure Python expressions slowly.

Overall it looks like we have to stick with z3c.pt at least for some
time.

Best regards,

-- 
Uli

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/grok-dev/attachments/20100301/ea80dc9d/attachment.bin 


More information about the Grok-dev mailing list