[Grok-dev] Re: Skinning/themeing

Fri May 18 23:14:48 EDT 2007

Quoting Martin Aspeli <optilude at gmx.net>:
Hi Martin,

> Kevin Smith wrote:
>
>
>> 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__)
>
> Yipes! I realise this is just an example, but the idea of using the
> docstring like that feels very dirty. :)

I would submit that for short clips, what documents a view class
better than the code itself? :)

>
>>    def render(self): pass # trick grok into not requiring     
>> app_templates/myview.pt
>
> Also yipes, but I'm sure this could be cleaned up.
>
>> 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..."
>
> I assume these names are there for ordering? That really strains the
> eyes, though. Why not something like:
>
> class MyFirstViewlet(quarry.Viewlet):
>     grok.viewletmanager(MyViewlets)
>     quarry.order(10)
>
>     ...

Actually, that's how I originally implemented it. In theory it seemed
like a great idea, but when I actually started coding with it,
viewlet class names seem to be too loosely connected to the
ViewletManager. It was difficult to ascertain which classes, like
ContactUs or Products 'belonged' to the Menu ViewletManager. So I started
naming viewlets to relate to the ViewletManager. Menu1, Menu2,
Menu3... at that point, I dropped the quarry.order() directive and
just sorted by class name.

For the record, my gut reaction is to avoid creating new grok
directives. I think it shares the same dangers as creating too many
new ZCML directives.

>> 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.
>
> That to me is bad convention-over-configuration. It's fine if names of
> things are used to find related things (view name -> template name).

Yes, that's what it's for, to relate viewlet name -> viewletmanager name.
This does bring up a good point, where is the line drawn for
convention-over-configuration. I think that Martijn and Phillip have
done a great job of deliberating this and I certainly defer to them in
these aesthetic matters.

> Having to artificially constrain names to get the results you want is
> really frustrating though. I *hate* aesthetically un-appealing code. It
> makes me think of Visual Basic for Applications. :-(
>
>> Viewlets are also be more view-l.ike so templates, self.url,     
>> self.application_url and the like are all available.
>
> Great!
>
>> 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.
>
> FWIW, I think template neutrality is YAGNI, and possibly harmful. It's
> a nice engineering challenge, and it helps enforce separation of
> concerns in code which are probably good practice, but as a user of a
> framework, I want the framework authors to have chosen the template
> solution for me. And I want all documentation and code examples to use
> the same language as well, so that half of it isn't irrelevant to me no
> matter which one I choose. How should I know which one is best for me,
> anyway, if I'm new to the framework?

Originally I thought that developers want choice. Which is
semi-sort-of the TurboGears approach and possibly more the Pylons
approach. But, especially after heavy use of viewlets and simple use
of macros (e.g. context/@@master/page), I agree. There's also the  
overhead of coding it. :)

ZPT's like the ZODB are breakthrough powerful technologies. Perhaps we  
should just embrace it.

>
> Martin
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev