[Grok-dev] Re: Paris sprint final report: Plone on grok!

[Martin Aspeli]

Lennart Regebro wrote:
> On Sun, Apr 27, 2008 at 7:11 PM, Wichert Akkerman <wichert at wiggy.net> wrote:
>>  Nice! It would be nice if the renderer would automatically be associated with
>>  the grok.Portlet if they are in the same file. Is that doable?
> 
> Probably, but I'm not sure of the best way. First I though we should
> do it with context, as a view, but then we realized we need to know
> what the renderer when we grok the portlet, and we did the current
> ugly hack.
> 
> Once possibility is to not register the portlet when we grok the
> portlet, but register it when we grok the renderer.
> 
> There is also the option today of having several portlets for one
> renderer, but not several renders for one portlet, 

First of all, the word "portlet" is ambiguous. Let's talk instead about:

  - A portlet assignment (the persistent, configurable thing you assign 
to portlet managers)

  - A portlet data provider (the thing that actually gets rendered)

  - A portlet renderer (a view of the data provider)

I kind of regret the assignment-vs-data-provider distinction. The 
IPortletAssignment interface has a "data" property which is supposed to 
return the data provider to use for rendering. The idea was to support 
the use case where you make one assignment type that e.g. lets the user 
pick a content item, and then depending on the type of content item that 
was selected, you'd get a different renderer.

However, in virtually all portlets, the assignment and the data provider 
are the same, so the convenience base class Assignment does:

  @property
  def data(self):
      return self

In fact, anything else is slightly dumb, since then the renderer doesn't 
have access to any settings configured on the assignment. Oh well. We 
may deprecate the "data" attribute and let the portlet retriever look up 
the renderer by adapting 'assignment' directly rather than adapting 
'assignment.data'.

Now, this all means that:

  - One portlet render could indeed be registered for multiple data 
provider types, since a renderer is really just a multi-adapter in the 
same way a view or viewlet is. However, I've never seen anyone actually 
do this, so I'd consider it an edge case.

  - A assignment type can have multiple data renderers for different 
types of data providers as returned by 'assignment.data'. Like I said, 
though, this isn't used very often, since in most cases 'assignment.data 
== assignment'.

  - A portlet renderer is a multi-adapter on '(context, request, view, 
portlet_manager, data_provider)'. You can have multiple renderers that 
vary on any of these. For example, you could have a portlet that has a 
different renderer in a particular view (that is, the current view 
that's rendered the whole page), or for a different portlet manager (the 
portlet looks different in the main column and the dashboard) or for a 
different context (the portlet looks different on a document than it 
does on other types).

So, I think the case of having one assignment type with multiple 
renderers is more common than having multiple assignment types using the 
same renderer.

> so my first
> instinct was to do them like they are views, but there it's the other
> way around.... So I'm not sure. This needs to be discussed with some
> Plone people. Especially optilude, I think. :)

Portlet renderers are certainly intended to act like views or viewlets 
(but with the extra adapter parameter that passes the "data 
provider"/assignment).

Cheers,
Martin

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