[Grok-dev] Re: Skinning/themeing
kevin at mcweekly.com
Fri May 18 19:07:31 EDT 2007
Martijn Faassen wrote:
> Martin Aspeli wrote:
>> Lennart Regebro wrote:
>> 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
The work of creating viewlets has been greatly simplified in
megrok.quarry (based on Lennart's megrok.viewlet work). For example...
<span tal:replace="structure provider:myviewlets" />
template = grok.PageTemplate(__doc__)
def render(self): pass # trick grok into not requiring
quarry.name('myviewlets') # provider:myviewlets
return "GROK SMASH..."
class MyViewlet_30(quarry.Viewlet): # using inline template
class MyViewlet_40(quarry.Viewlet): # using common templates
return ['PHP', 'ASP', 'RUBY']
... add as many viewlets as you need.
The viewlets are automatically ordered by view name. Viewlets are also
be more view-l.ike so templates, self.url, self.application_url and the
like are all available.
>> 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.
> We have many details to work out, such as ordering issues. Which
> MatchViews get applied first? What if you have a whole-page MatchView
> and then also ones that match smaller bits?
> 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.
In ZPT land, Deliverance and MatchView are orthogonal to viewlets. When
used properly, they are a much simpler and powerful mechanism for
creating pluggable UI's like Trac uses. If however, Grok were template
neutral, I'm not sure what kind of a role *if any* viewlets could play.
> Grok-dev mailing list
> Grok-dev at zope.org
More information about the Grok-dev