[Grok-dev] Re: Skinning/themeing

kevin at mcweekly.com kevin at mcweekly.com
Sun May 20 03:03:44 EDT 2007

Quoting Martijn Faassen <faassen at startifact.com>:

> Martin Aspeli wrote:
> [snip]
> 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 perspective
> * 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.

Using another template language today is simple enough using the  
render method.

from mako.template import Template

class MyView(grok.View):
     def render(self):
         return Template("hello ${data}!").render(data="world")

Certainly that's not very conducive to reuse, so one could take a  
quasi-TurboGears approach and use dotted names.

class MyView(grok.View):

In the past I've advocated template neutrality, however...

* will grok be able to be template neutral fast enough
* will the developer base be able maintain it ... docs too
* will it splinter a small community base too much too soon

I think that template neutrality, and most of the lastest  
skinning/theming debate is exposing an altogether different issue.

Is grok a my-way-or-the-highway framework, or a framework of choices?

It's a hard balance though. Newbies needed to be exposed to as little  
as possible and be given as much direction as possible. Experts need  
access to everything and express themselves with as little limitations  
as possible.

Personally I find grok so intuitive, that I barely think of grok as a  
framework at all. It's what attracted me to grok to begin with. It's a  
set of tools that get the job done fast.

I prefer grok to be a frame work of choices.

Best Regards,

Kevin Smith

More information about the Grok-dev mailing list