[Grok-dev] Re: Skinning/themeing
optilude at gmx.net
Fri May 18 03:34:30 EDT 2007
>> I know there was a debate on this a while ago, but having done some
>> thinking, and in light of the experience of writing Plone 3, I feel that:
>> - We ought to have a standard way of sharing UI structure.
> It might be wise for grok to stay out of the CMS business for awhile. I
> believe there are plans in the GSOC to flesh out the administration ui a
> bit, but only for basic maintenance and configuration tasks. Such as
> delete/rename, etc. That's a good thing, IMO.
>> This is analogous to main_template in Plone
Agreed. I wasn't being very clear... Standard UI affordances should not
be in Grok core IMHO (apart from basic management UI). I was talking
more about patterns and things we make easy - i.e. the pattern of having
a main_template-like-thing (or @@standard_macros/page or whatever) to
define common page structure, with individual views using this (filling
a central slot). We don't have to define the template or the slot, just
make it easy to set up this kind of thing.
>> - We ought to promote a standard set of viewlets
>> Viewlets are great. They make it easy to write general components,
>> such as ratings (with annotations, which are also great) or tagging or
>> information boxes. It'd be useful if there was a semi-standardised
>> vocabulary of viewlet managers that applications could use. This would
>> mean we'd get the same name for similar elements of applications' UI,
>> making it easier for other code to plug itself into those viewlet.
> Viewlets are awesome. I've done some work to make them easier to use and
> behave more view-like in the megrok.quarry repository.
>> - We ought *not* to write our own themeing engine.
>> For this, I think we should embrace Deliverance. :)
>> Plone very much wants to move in this direction, where ZPT's are used
>> to define page structure and shared elements (which are also good at),
>> and plain-HTML theme files with Deliverance rule files are the way to
>> go for the end look-and-feel (which is much more designer-friendly).
>> Simple applications won't care. Simple applications will just
>> hard-code look-and-feel into ZPTs. Simple applications don't need
>> anything more complex or powerful for skinning/themeing. Simple
>> applications possibly even want something simpler than ZPTs.
>> Complex applications, or those where designers are different people to
>> coders, or those that want to be extensible and skinnable, do need a
>> themeing system. Rather than inventing a new one, I think Deliverance
>> continues the Grok mantra of simplicity, elegance and innovativeness.
>> I know some people have already started looking into this marriage,
>> and I'm really keen to hear of their experiences.
> Perhaps this a bit too black and white. I think there is a lot of middle
> ground here. None of my use-cases yet warrant a full-on Deliverance, yet
> they *always* require seperate admin/public skins.
Right. The two use cases may be orthogonal - I mean, if "admin skin"
really just means that admin-like views use a different "main_template"
or equivalent, then that's something I'd bucket wit the "Simple
However, if Deliverance was very accessible to you, I think (hope) you'd
find that it'd save you time to deal with prsentational markup and CSS
at that level, rather than intermixing this with the bits of
ZPT/TAL/METAL which are really about building up the semantic
*structure* of your pages.
>> To my knowledge, to make this happen, we would need:
>> - To nudge the Deliverance build/install/deploy story along a little
>> further. It's not too bad, it just needs an installer or an egg or a
>> buildout recipe, and some better Windows support.
>> - A developer-friendly way of configuring Deliverance - probably as a
>> filter using the Twisted web server and WSGI.
>> - Some Grokkable conventions for storing theme files and resources
>> - Documentation and patterns an examples :)
> I am -1 for making Grok a CMS
Me too, most definitely. I think I wasn't very clear there.
>, and +1 for using grok to creat a
> stream-lined CMS with a standard API, though this sounds suspiciously
> like the beginning of grok.Monolith, the port of Plone to grok. ;)
Hehe. I wouldn't go there. :)
> PS: Definately look at Darryl's work, besides using Deliverance, he's
> even done a port of Plone portlets to grok.
Yep. I know about that, and it excites me. ;)
More information about the Grok-dev