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
>>>> 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
>>> 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
>>> 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.
>>> Option 2:
>>> When we display the view, we select a different master page than the
>>> one. This special master page has portlets that the view wants to
>>> be displayed.
>>> or none of the above? :)
>> 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.
> 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
> 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
in that case, using a portlet to display the poll results might not be
the best solution, but in case you'd want to display the poll result on
the front page of your site, you'd have no choice but to use a portlet.
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 ...
Zope3-dev mailing list