[Grok-dev] Re: Skinning/themeing

[Martijn Faassen]

Hey,

Martin Aspeli wrote:
[snip]
> I think Grok should have a convention for defining something like
> @@standard_macros, which would probably contain a macro for the standard view
> (and maybe one for admin screens), with an associated template that defines 
> slots.

Zope 3 has some kind of a way to aggregate macros that I never quite 
understood the purpose of - it seemed unnecessarily complex.

Anyway, if you have a page template which defines some macros, put it in 
your application's templates directory, say app_templates/mymacros.pt

Then in app.py:

class Mymacros(grok.View):
      grok.context(Interface)

You can now access macros using:

metal:use-macro="context/@@mymacros/page"

Fairly simple pattern. We could make a grokker for this case, though 
it's barely worth it, if at all.

> This to me is the first step of promoting patterns for skinning and templating.
> Most people who aren't used to this kind of "inversion of control" in templates
> start trying to include a standard header and footer "include" on each page.
> That's fine - we should (and do) support that, but in my experience it's not a
> great way to grow an application (you end up with a "change all templates"
> exercise at least once, probably more times, as your design evolves).

A bit in the tutorial would be helpful here to start with, then.

[some conditions for integrating deliverance]
> My point was that we may eventually end up creating our own portal_skins. That
> is, a standard component which keeps track of installed themes and lets people
> switch between them. Maybe not in the core of Grok, but if Grok is about coming
> up with "the way" to solve various common use cases, it's likely that something
> like this would emerge as a "semi-supported add-on".

I think a skin switcher could be part of a Grok admin interface. The 
problem of course is that skins should be related enough - skins only 
work if they define the right slots.

This is a limitation of the whole macro mechanism. I've never really 
been entirely happy with macros. I hope we can fix this with an 
in-processing post-processing approach, where you can apply views on 
HTML generated by other views using XPath expressions (along the lines 
of match templates in Genshi). I realize this is not the normal Grok 
approach where we codify existing patterns, but I am not that thrilled 
with the existing pattern here. :)

> At that point, I'd like to defer to some of the experience from Plone, which
> tells us that:
[snip plone experience]
> It's this last point where we wish we'd been thinking a bit more. Developers 
> are normally not great a design, and designers are normally not comfortable with 
> the ZPT approach, because it's alien, and because pages are composed across several
> files (typically, the view + main_template + the things that main_template
> includes + various viewlets).

It's good that we agree we should think this through.

> Deliverance separates the concept of the visual theme (which is an HTML world)
> from the concept of building a semantic representation of the page (which is 
> the in the ZPT world). 

> Like I said, in simple applications these tasks are 
> performed by the same person, who may not care about separation or even care that much
> about visual look-and-feel, settling for something quite rudimentary. However,
> when the time comes to make that leap, or even for developers who prefer to do
> the visual fluff at the end, I think this separation would be useful.

Such a separation is indeed attractive. I'm worried about the conceptual 
overhead it entails for the simple case. For many smaller applications 
doing this separation isn't worth. Grok in other areas tries to bring 
things closer together (without losing flexibility, hopefully), and 
introducing a strong separation between theme and template pulls in the 
other direction. Note I'm just expressing worries - I think these 
potential problems might be overcome, we just should be aware of them.

> Also, Deliverance exists and has growing mindshare. Better to use it than to
> invent something similar-but-different, imho.

Yes, true. One reason I'm attracted to Genshi-style match templates is 
because I suspect we may be able to reuse Genshi's machinery to 
implement them. The new invention would be Grokkers and tying it up to 
the existing grok view concept.

[snip]
> It doesn't have to be an all-or-nothing approach. It doesn't even have to be
> Grok-specific. In fact, it may better if it isn't. Deliverance is about a
> pipeline, so it may be that this takes the form of, say, a buildout recipe to
> get Deliverance set up plus some configuration boilerplate for getting this 
> into a Twisted/WSGI pipeline or some such (in this scenario, I don't think you need 
> a separate process, but I may be wrong).

That's a good point. Philipp is doing some work with WSGI and Zope 3, so 
we could talk to him.

Regards,

Martijn