[Zope3-dev] [DRAFT] local portlets and perspectives

[Jean-Marc Orliaguet]

Jim Fulton wrote:

> Jean-Marc Orliaguet wrote:
>
>>
>> yes, these would be application-specific portlets, as the ones used in a
>> calendar application for instance showing a monthly agenda. The portlet
>> gets access to the current view object, to the current page location
>> (renamed from 'context_obj' to 'location'). So as soon as you can
>> produce some data from that you have a portlet that can be put inside a
>> theme page.
>
>
> I don't understand this.  Does the application page use a theme page
> to render it's output, which then gets inserted into the o-wrap produced
> by another theme page?  Or does it use a different o-wrap theme-page
> which includes the portlets it wants to be displayed?
>
> Or, put another way, which of the following strategies are used:
>
> Option 1.
>
>   We render the master page (o wrap), which calls the view.  The view
> then
>   finds another theme page that has portlets it wants. The view renders
>   this theme page and returns the result to the calling master page,
> which then
>   renders the whole page.
>
> or
>
> Option 2:
>
>   When we display the view, we select a different master page than the
> usual
>   one.  This special master page has portlets that the view wants to
> be displayed.
>
> or none of the above? :)
>
> Jim
>

an application designer would have two choices:

1) provide views just like any zope3 does already, and use cpsskins to
decorate the page with portlets around the main view, very much like the
current ZMI interface, with breadcrumbs, some navigation, some actions,
with the difference  that there is no need to write CSS since there is
already a style editor that takes care of that.
also the portlets can be moved on the canvas without touching any
main_template.pt or zpt.

2) write portlets instead of views, that will be placed on a page as any
portlet would. One could write an XForm rendering portlet (Julien is
working on something like this), or a document portlet that renders some
document, etc..

 but then we get back to the original subject of the discussion: once
you have application specific portlets, you need to introduce the notion
of perspective (or contextual usage) otherwise you won't be able to know
when to display them.

for instance it is OK to display an action portlet on every screen of a
portal because there will always be an action to show and action items
are highly contextual, but for some portlets or groups of portlets that
are too specifically tied to a given activity in the application, this
won't do.

remember that unlike the objects in <browser:page /> no portlets is
associated to object types, portlets are associated to cells (global
portlets) or to slots (local portlets)

So the idea behind perspectives (as in Eclipse SDK) is to create a sort
of contextual usage but for local portlets that can be used by the
application to update the interface according to the current activity of
the user.

/JM