[Grok-dev] Re: Giving viewlets "the grok treatment"?

[Martin Aspeli]

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 
page.

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 
content provider.

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.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book