[Grok-dev] Re: Giving viewlets "the grok treatment"?
optilude at gmx.net
Sat May 10 08:54:34 EDT 2008
Ethan Jucovy wrote:
> But at least in my experience, I've found that this flexibility simply
> isn't what I need. Many times, I only use viewlets as a way of
> injecting content into a page in a nice decoupled way. That is,
> usually I don't care about reusing viewlets -- I just want to define a
> couple of viewlets that can plug into a single page, without needing
> them to plug into multiple pages. Heck, most of the time I don't even
> care about sorting and filtering.
> In other words, most of the time I don't really care about any of what
> a viewlet manager provides.
In Plone, we use viewlets in order to provide a pluggable UI. Plone is a
rich application and each page has a lot of stuff going on. By defining
some useful "insertion points" - viewlet managers like "above the
title", "below the main content" etc - we can let third party authors
plug themselves into the Plone UI without needing to customise an entire
I think if you're not building that kind of "pluggable UI", then
viewlets are possibly less useful. Your code example looks to me much
more like macro-includes than viewlet slots.
Now - zope.viewlet is built on zope.contentprovider. Both viewlets and
viewlet managers are content providers. The "provider:foo" TAL
expression type is capable of rendering any content provider (that is, a
named multi-adapter on context,request,view that provides
IContentProvider). A viewlet without a viewlet manager is basically a
Perhaps Grok should have a grok.ContentProvider base class that register
a simple content provider?
It's also worth looking at how Vudo are using viewlets. There is a
problem currently in that the rendering model really wants all
viewlets/content providers on a page to get updated()'d first and then
render()'d. Since ZPT renders things as it goes along, it can't call
update() on all content providers before the page is rendered - it has
no idea what content providers there're going to be! In Vudo, I think
they solve that by declaring all content providers explicitly in the
View class and having a simple API to render them out. The view itself
then loops over all its content providers and calls update() on each
before rendering the page.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
More information about the Grok-dev