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

[Jim Fulton]

Jean-Marc Orliaguet wrote:
> Jim Fulton wrote:
> 
> 
>>Jean-Marc Orliaguet wrote:
>>
>>
>>>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:
>>
>>
>>I guess these are both in the "none of the above" catagory. :)
>>
>>
> 
> 
> or both, given that they annihilate one another : -)
> 
> 
>>>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.
>>
>>
>>But this doesn't let me use portlets in the main view.  What if I
>>wanted my results page in the poll example to use a particular portlet.
>>Is there a way to do that?
> 
> 
> 
> yes, but with:
> 
> - a "poll results" portlet
> - some information that says when to show the portlet (cf perspectives)
> 
> you'd need a "poll" perspective to control which portlets to display.
> 
> the fact that the main area is taken by the macro-slot portlet with the
> risk that it will render the original template view is not a problem
> since you can place it inside a slot and turn it into a local portlet.
> 
> from the "poll" perspective you'd decide not to display the main-macro
> portlet, since another portlet is taking care of displaying the results.
> 
> 
>>>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.
>>
>>
>>So, my results page, instead of being a normal view is a portlet. 
>>Suppose
>>that my original goal in my results page was to display the results along
>>with some other portlet. Now, I split my results page into a portlet
>>that I wanted to display and the original portlet that I wanted to
>>display.
>>Now, I have to somehow, through perspectives or some rule-based approach
>>arrange to have my to portlets displayed in the two desired places on
>>the page.
>>This sounds like a very round-about way to just display a page with a
>>portlet.
>>
>>Jim
>>
> 
> 
> in that case, using a portlet to display the poll results might not be
> the best solution,

Right, but then what if, when displaying the poll results, I wanted to use some
other portlet.  Perhaps I have a portlet that lists the top 10 polls
and I want to display that within the content well (inside the
o wrap) when I display my results.

Limiting portlets to master pages (o wrap) seems to me to be a needless
and complicating limitation.

...

> then the actual question is:  why should a page in a zope3 application
> only display one view of an object at a time? i.e. the main view? when I
> read my mail I have 4 different views of my mailbox, not just the text
> contained in the mail ...

Exactly. So, perhaps I have a mailbox.  The main view for the mailbox
uses 3 portlets:

   - a mailbox listing portlet

   - a portlet that lists all my mailboxes

   - a portlet that displays a selected message

Why can't I specify these three portlets in the definition of my
mailbox view?  Why should I have to tease them into the master page?

I'd like to be able to design my individual application pages
and the master page independently.  If I can only display portlets
in master pages, then either:

1. I can't use them when designing individual application pages, or

2. I have to sneak the contents of my applications into the master pages,
    which seems to be a far more complicated model, conceptually, let alone
    computationally.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org