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:[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
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
