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

[Jean-Marc Orliaguet]

Jim Fulton wrote:

> 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
>

I'm going to set up a prototype to demo the concept of perspectives, the
idea is generic enough I think and independent of the actual
implementation I think.

Concerning unification:
During the sprint in Göteborg in June  according to what Tres mentionned
it appeared to me said that the issue was to make portlets independent
of any macro mechanism, and that the they should be treated as page
fragments without any assumption about where on the page or inside which
template they'll be displayed.

the idea was to chop the page into pieces and reuse the pieces.

the rendering engine in cpsskins is designed to do layouting/styling of
the "O wrap" area in the way that *web designers* are used to work with.
By using "perspectives" end-users can also use the portlet editor to
move portlets on the canvas (as in the google news portal), all that is
needed is a portal page with three slots in it....

If the application contains portlets in the O wrap area, it will work
too. The Schoolbell application is such an example where every box could
easily be converted into a portlet and be displayed according to
"perspectives".
http://www.schooltool.org/screenshots/shots-sb10/sb10-day.jpg

This is what I meant with having a "unifying concept". And that sounds
very unifying to me already.

But when it comes to the content well, I strongly think that the
layouting is best delegated to other rendering engines, XForms, for
instance (Julien could tell you more about it), iCal renderers, Flash
plugins, etc.. Otherwise you will lose the generic aspect of cpsskins,
and the layout engine will become extremely complicated to manage. I
think that the content well should in that case be *one* portlet that
knows how to do its own layouting and not be a mixture of portlets.

rendering a weekly calendar view would otherwise be a real pain if the
meetings booked were portlets...

In CPSSkins for Zope2 for instance it is still CPSDocument that creates
the layout of documents and it is best done that way I think.

have a nice week-end!
/JM