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
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:
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,
renders the whole page.
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
or none of the above? :)
an application designer would have two choices:
I guess these are both in the "none of the above" catagory. :)
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?
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
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
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
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 Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list