[Grok-dev] Re: Skinning/themeing

Fri May 18 19:07:31 EDT 2007

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.
The work of creating viewlets has been greatly simplified in 
megrok.quarry (based on Lennart's megrok.viewlet work). For example...

class MyView(quarry.View):
    """<html metal:use-macro="context/@@master/page">
       <body metal:fill-slot="body">
       <span tal:replace="structure provider:myviewlets" />
       </body>
       </html>
      """
    template = grok.PageTemplate(__doc__)

    def render(self): pass # trick grok into not requiring 
app_templates/myview.pt

class MyViewlets(quarry.ViewletManager):
    grok.context(MyView)
    quarry.name('myviewlets') # provider:myviewlets

class MyViewlet_10(quarry.Viewlet):
    grok.viewletmanager(MyViewlets)

    def render(self):
        return "GROK SMASH..."

class MyViewlet_20(quarry.Viewlet):
    grok.viewletmanager(MyViewlets)

    def render(self):
        return "ZCML"

class MyViewlet_30(quarry.Viewlet): # using inline template
    """<b>SQL</b>
    """
    grok.viewletmanager(MyViewletManager)
    quarry.template(__doc__)

class MyViewlet_40(quarry.Viewlet): # using common templates
    grok.viewletmanager(MyViewlets)
    quarry.template('myproject.common.boxlayout')

    def entries(self):
        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.
> Regards,
>
> Martijn
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev
>

Kevin Smith