[Grok-dev] Re: Skinning/themeing
optilude at gmx.net
Fri May 18 08:43:33 EDT 2007
> Since you say yourself you weren't very clear, could you summarize your
> proposal? My first reactions:
Not so much of a proposal as a discussion, but yeah. Let me reply to your
> * I think Grok should stay out of the business of providing standard
> templates and slots for the time being. You can argue Grok needs to
> provide standard policy here, and it's not a bad argument. I'm just
> worried we'd be locking in on a solution too soon.
I'm not so much concerned about actual templates, as I am about patterns. For
example, one common pattern is Zope 3 is:
This assumes that there is an @@standard_macros view and that it has an
attribute called 'page' which refers to a macro.
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
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).
> * I agree with Kevin Smith that deliverance is overkill for many use
> cases. *If* we can make this install beautifully out of the box and *if*
> there is no additional overhead for the developer because he's dealing
> with two processes and two ways of doing things then this might be okay,
> but we'd need to see this work first before we recommend this as a pattern.
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".
At that point, I'd like to defer to some of the experience from Plone, which
tells us that:
1. Developers understand ZPTs and like the way in which the macros-and-slots
mechanism allows them to build common look-and-feel (or rather, common page
structure) across different views of objects
2. ZPTs, being (mostly) well-formed XML are quite good for building semantic
3. "Skinning" a site in Plone typically means (a) overriding CSS (via a
registry of active CSS files, but that's very specific) and (b) changing
main_template to get the basic structure right; sometimes it also involves (c)
changing/customising various other templates (using the portal_skins layers
approach, or browser layers on Z3 views).
It's this last point where we wish we'd been thinking a bit more. Developers
normally not great a design, and designers are normally not comfortable with
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).
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
in the ZPT world). Like I said, in simple applications these tasks are
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.
Also, Deliverance exists and has growing mindshare. Better to use it than to
invent something similar-but-different, imho.
> * In the invention category there are some ideas floating around
> concerning views on HTML page fragments. That is, they're mostly
> floating around in my own head, inspired by Genshi's match templates. Of
> course since there is nothing there yet macros/slots are still the way
> to go.
I hope they float out eventually. :)
> A better UI theming experience is one of the areas where I think Grok
> might want to do some innovation above what's already available in Zope
> 3 land. Both my ideas and integrating deliverance would classify as
> innovation. Deliverance is definitely a more proven technology at this
> stage, of course.
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
a Twisted/WSGI pipeline or some such (in this scenario, I don't think you need
separate process, but I may be wrong).
More information about the Grok-dev