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

[Ethan Jucovy]

Hey Martin,

On Sat, May 10, 2008 at 8:54 AM, Martin Aspeli <optilude at gmx.net> wrote:
>  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.

Well, I am actually building a somewhat pluggable UI, but with a
fairly rigid and narrow set of "entry points" like "project creation
options", "project info options", "user account options", etc.  So I
don't need a whole lot of rich options about how things plug into
those particular places, but I do need a way to aggregate and display
an arbitrary number of UI plugins without knowing what they'll be.  I
don't have very much experience with "vanilla" content providers; can
they provide that aggregation for me by default?  (That is, without my
writing extra code in the content provider which aggregates broadcast
plugins before returning them to the template.)

I may be wrong, but my rough abstract understanding of viewlets and
content providers is:

 * Content providers let you plug any, but not all, of (X, Y, Z, ...)
into A, by allowing a single lookup on (context, request, view).
 * Viewlets with viewlet managers let you plug any or all of (X, Y, Z,
...) into any or all of (A, B, C, ...), by allowing a single lookup on
(context, request, view) for the viewlet manager which then does a
multi-lookup on (context, request, view, manager).

Viewlets with viewlet managers let you reuse the viewlets in any
number of places, by abstracting a layer between the viewlet and the
view, and allowing viewlets to associate with any number of managers
which themselves associate with views.  This seems perfect for a
general-purpose sort of system like Plone, where a single slot could
be filled by six widgets, and a single widget could be inserted into
six slots.  But for my far less general-purpose app, what I find that
I really want is to plug any or all of (X, Y, Z, ...) into A.  In
other words, I want any number of things to be "pluggably" inserted
into a single template, but I don't need those things to be reused by
other templates since my entry points are so specific.

So I'm not exactly proposing viewlets without viewlet managers --
rather, I'm proposing viewlets with *hidden* viewlet managers, where
Grok handles all the details of those viewlet managers, and as far as
the end user is concerned the viewlets are just being plugged directly
into views in a decoupled, but not reusable, way.  I think that would
solve my particular pluggable-ui problem easily (though if I'm wrong
about how vanilla content providers work and they already allow this
by default, then you're right that my idea is pointless ;)) and -- in
keeping with the Grok philosophy -- in a general way that doesn't rule
out future complexity if it later becomes apparent that explicit
viewlet managers are needed.

I'm sorry if I'm being terribly unclear; I'm having a bit of trouble
figuring out how to actually talk about this, and I have a feeling I'm
muddling the issues a bit.  Maybe I should just try to write some code
instead?  ;)

egj