[Grok-dev] Re: Skinning/themeing

[Martin Aspeli]

Martijn Faassen wrote:
> Martin Aspeli wrote:
>> Lennart Regebro wrote:
>>
>>> Sure:
>>> http://mail.zope.org/pipermail/grok-dev/2007-March/000476.html
>> I see! This looks very powerful and cool.
>>
>> I assume we are still considering viewlets as the way of making 
>> "pluggable" UIs, i.e. aspects of a page where you can plug in new 
>> elements without modifying the view, and where you can vary the thing
>>  being plugged in by context type.
>>
>> Or are we thinking this is the general approach to page composition?
> 
> I admit that though I've seen them in use in Schooltool (and being put 
> off by the tremdendous amount of ZCML they seemed to need) and after 
> having listened to Philipp's talk about them at last year's DZUG 
> conference, I still don't grok them. Philipp's talk was fine, I think 
> that's because I haven't actually tried to use them myself yet, so they 
> don't stick in my brain.
> 
> So my answer to this: I don't know. :) I'm hoping Lennart has a better
> answer.

To systems like Plone, viewlets are very useful, because they allow you 
to make pluggable UIs. For example, in Plone 3, we have tons of viewlets 
for things like "above title" and "below content". This makes it easy to 
plug in things like ratings, discussions etc from third party products.

Not all (most?) Grok apps will need that level of generlisation, but if 
you need something more powerful than a "macro include" (e.g. the 
ability to vary the viewlet based on the type of context or the type of 
view) then they are very flexible and imho quite easy to use (though 
some grokking wouldn't go amiss).

For example, in Plone 3, we've invented an IViewView market interface, 
which we apply to the view that is the "view" tab of an object. This 
allows us to add viewlets which show on the main view of a page, but not 
on secondary views (e.g. an edit screen). This kind of control makes 
re-use of visual elements easier.

Again, the registration side of things (for viewlet managers as well as 
for viewlets using these managers) could be made easier in a Grok world, 
though.

>> Also I'm not convinced that it solves the general themeing/branding
>> problem. The premise of Deliverance (or something like it) is that
>> the designer (be he the same or a different person to the one doing
>> the compositing and the raw development) makes a full, flat, static
>> HTML page (or pages) which defines "the way it should look", and then
>> pulls the relevant parts of the "composed" page into the correct
>> parts that static page. That allows them to use familiar tools (e.g.
>> Dreamweaver) and design a "whole" into which the application slots
> 
>> The match approach described in the email above, as I understand it,
>> is about defining a pipeline which post-processes the "bits" of a
>> page (which is of course useful for all kinds of things). It works
>> the opposite way to Deliverance, in that you start with a "composed"
>> set of markup and then selectively swap out bits of it. I can't see
>> how someone wearing ad designer hat would make lots of these little
>> match classes and template snippets to theme a page.
> 
> Actually there are two places to use xpath with MatchViews. One place is
> to match with part of a page. That could be a part of a page, but note
> it could also be the whole page.
> 
> Then the second place where you can use xpath is to pull in bits of the 
> matched HTML.
> 
> So, you could set up a match view that matches with the whole page. The
> template would be a fully themed page. It would pull in bits of the
> original page using xpath.
> 
> I think that this means we could do what you describe Deliverance does. 
> Hopefully we also allow the user to still access the original context 
> object somehow, to get information from it the python-way. This breaks a 
> pure pipeline model (which has definite advantages) but the gain in 
> expressive power may be worth it.

Ah, I didn't realise that! That sounds closer to what I was envisaging. 
It becomes a question of patterns then. We need to make sure people 
don't shoot themselves in the foot and make a mess of "compositioning" 
and "branding" code spread across the "actual" view and any "match views".

> We have many details to work out, such as ordering issues. Which 
> MatchViews get applied first? 

Within a module, I think it should just be the order in which they're 
defined. Across modules, well...

> What if you have a whole-page MatchView 
> and then also ones that match smaller bits?

You could order it so that more general things go first, but I think 
that'd be very expensive. A simple order-of-definition pipeline makes 
sense to me, where the thing matched in the second matchview is the 
output of the first matchview.

> I'm not guaranteeing any of this will actually work in practice. :) One 
> thing we should definitely do is to make a careful study of Deliverance 
> before we start implementing this. I also need to get a better picture 
> of how viewlets fit into all of this.

Agree.

Martin