Jean-Marc Orliaguet wrote:
Jim Fulton wrote:

Jean-Marc Orliaguet wrote:

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.

If it's just a matter of visual layout, you only need to add a slot
inside your theme just below or above the main-macroslot where you can
put the poll portlet (main top, and main bottom slot) as you'd find in
any zpt-based template.

But then, I have to much with the theme just to get my page to
come out the way I want.

But, maybe it's not a good idea to use the same mechanisms
for the o wrap and the content well. More on this later.

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

Or maybe a good idea ...


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


all you need to know when you design your application is the name of the
slot in which the portlet will be displayed (right slot, left slot,
etc.) This was already the case CMF's where slot names
where hardcoded.

then in a zcml declaration of the perspective you can specify the slot
in which the portlet will be displayed.

in some way you'll have to tell *where* the portlets will be located on
the page, this is what you do with the "fill-slot" use-macro attribute

But I want to control where the portlet will go in the content well, not
in the o wrap.

It could be argued that different mechanisms should be used for the o-wrap,
content well, and end-user portlets (ala JSR 168).  This gets back to
Gary's point the other day that there are different actors and use cases
that *could* be unified, but that maybe it's not a good idea to, from a UI

Site designers define the o-wrap (possibly many).  When they design the o wraps,
they define the position of the content well and other portlets, and they can
also define slots where content managers can place additional portlets.
(I suppose an o wrap could define 0 or more content wells).

Page designers (for specific applications) design pages that go in the
content well (or maybe content wells).  When designing the contents of
the content well, they too might want a system that lets then combine
page or content components (ala the email interface).

Content managers have some UI for arranging portlets within slots.

End users might have portlets that they can arrange within slots as
well (ala JSR 168).  (BTW, we find the use of the word portlets
for JSR 168 portlets and for the things that site designers,
page designers and content managers drag around to be pretty

Anyway, at this point, I think I understand the basics of
CPSSkins, hopefully enough to think about your arguments for perspectives.
I'll do that thinking and get back to you Monday.

Have a good weekend.


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to