[Zope3-dev] [DRAFT] local portlets and perspectives

[Jim Fulton]

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
>>alone
>>   computationally.
>>
>>Jim
>>
> 
> 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 main_template.pt 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
perspective.

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
confusing.)

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

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org