[Grok-dev] Re: Skinning/themeing

[Martin Aspeli]

Hi Kevin,


>> 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.

Cool. :)

>>  - 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 
applications" above.

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 :)
>>
>> Thoughts?
> 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. ;)

Martin