[Grok-dev] Re: Skinning/themeing
faassen at startifact.com
Sat May 19 16:53:08 EDT 2007
Martin Aspeli wrote:
> FWIW, I think template neutrality is YAGNI, and possibly harmful. It's a
> nice engineering challenge, and it helps enforce separation of concerns
> in code which are probably good practice,
It also supports evolution of the framework over time. I.e. you can
introduce a new templating language evolutionarily and you're not locked
into the same template language forever.
> but as a user of a framework,
> I want the framework authors to have chosen the template solution for
> me. And I want all documentation and code examples to use the same
> language as well, so that half of it isn't irrelevant to me no matter
> which one I choose. How should I know which one is best for me, anyway,
> if I'm new to the framework?
These are all points and it's one of the things that's been nagging me
about the goal of template language neutrality. Some benefits though:
* as you mentioned: separation of concerns
* evolution potential: we'd not be locked into ZPTs forever
* ability to reuse existing code surrounding Buffet (or Smorgasbord). A
whole range of template languages become available.
* Grok/Zope 3 can "get out of the template language business"
I actually have two goals here:
* template language neutrality would be good from an architecture
* I want to move away from ZPT as Grok's template language.
I'd be interested in seeing whether we can use Genshi. It's conceptually
similar to ZPT. It doesn't support path expressions, but I am thinking
more and more path expressions are hurting us more than they gain us.
They're shorter, yeah, but only because python expressions in ZPT
require you to type: 'python:'! More readable? More comprehensible? I am
skeptical. (genshi incidentally does make foo.bar and foo['bar'] mean
the same thing, if I recall correctly)
One of the reasons I advocate template language neutrality is so we can
get in a new template language *at all*. If we simply replace ZPT with
Genshi, our code will break. That's rather too drastic.
I think Grok should do the following:
* become template language neutral
* promote 1 template language in all its examples and own codebase.
* offer an advanced usage where you can throw in templates in other
languages. It would be best if we could do this on the Zope 3 level
itself, but that's probably a major assignment we can't take on, so we
may end up doing it for Grok.
More information about the Grok-dev