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

Lennart Regebro regebro at gmail.com
Sun Apr 27 16:39:58 EDT 2008


On Sun, Apr 27, 2008 at 9:55 PM, Martin Aspeli <optilude at gmx.net> wrote:
> 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.

Ah, *that* explains that weird "Assignment" thingy. I think we want,
for the grokky-thingy. to not have to create an assignment unless we
want this distinction. We just want a data provider, and we want to
call it "Portlet", imo. It may be ambigous, but it's what people
expect to do.

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

I agree.

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

Ah, right. So they should probably be defined as you define views,
with the assignment being the context.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64


More information about the Grok-dev mailing list