[Grok-dev] Skinning/themeing

[Lennart Regebro]

On 5/18/07, Martin Aspeli <optilude at gmx.net> wrote:
>   - We ought to have a standard way of sharing UI structure.

Totally. Martijn wrote a great plan for how to do that. I plan to
implement that during the EuroPython sprint, unless somebody else does
it first. I haven't looked at what Darryl has done yet.

>   - We ought to promote a standard set of viewlets

Totally.

>   - We ought *not* to write our own themeing engine.
>
> For this, I think we should embrace Deliverance. :)

I don't agree. And one reason for that is that viewlets get
complicated, because you need to make a separate http request for each
viewlet.

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

Yes, but without a theming engine, we won't have any shared elements.
Getting the viewlets there is a part of the theming. Plone solves this
by using a macro, but that locks you into ZPTs only.

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

This is how the planned engine specified by Martijn works too, So it's
a deliverance type of theming engine, but inside of zope, and most
importantly, it can do the theming with a context, which deliverance
can't, since it's outside of the server.

Kevin Smith:
> I am -1 for making Grok a CMS, 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. ;)

I agree completely.

On 5/18/07, Martijn Faassen <faassen at startifact.com> wrote:
> Hey Martin,
>
> Since you say yourself you weren't very clear, could you summarize your
> proposal? My first reactions:
>
> * 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 don't think it should necssarily be a  part of grok, itself. It
should require Grok, though. :-) As long as it's separate, it's not a
lock-in.


-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64