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 _______________________________________________ Zope3-dev mailing list [email protected] Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
