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

[Jean-Marc Orliaguet]

Jim Fulton wrote:

> Jean-Marc Orliaguet wrote:
>
>> Jim Fulton wrote:
>>
>>
>> I've read the article, it is clear to me that the main idea is to be
>> able to reuse components, not to create a collection of web pages just
>> to present an application from a slightly different perspective.
>
>
> OK, then we have very different perspectives on perspectives.
> I see eclipse perspectives as primarily a way to tailor the UI
> to the task at hand, which, BTW, I don't see as simply
> persenting an application from slightly different perspectives.
>

for me the Eclipse definition is a subset of what I mean. I took it as
an inspiration, the application of perspective needs not be restricted
to UI tasks. Again a perspective can be seen as a skin for portlets. It
is as if you'd claim that skins can only be used in some situations and
not in others..

>
> > With 3
>
>> master pages and a set of 5 perspectives you get 15 combinations. That
>> would be 15 pages in html to maintain.
>
>
> Perhaps, although it's not clear to me that separate perspectives
> would want to share the same master pages.  To be honest, it's
> not clear to me that different applications would/should want to mess
> with the o-wrap in the first place.
>

Use case: you are looking at a site from some "external website"
perspective (cf. zope.org) you want to change the content of some
document. So you need to interact with an action box that is invisible
to anonymous users, and interact with a navigation portlet to find
documents. Are you going to create a new zope.org page for that? Or just
switch to the "web publisher" perspective?

>> The main idea is to define visibility in a coherent way,
>
>
> We're both in favor of that.
>
>
good, I think that it is about time we find areas of agreements ..

>> not with a
>> series of CSS hacks (hidden {display:none}), <div
>> tal:condition="not:first_login" >...</div>, <img tal:condition="python:
>> current_path.startswith('/section/news')">, scattered around 100 page
>> templates... or by using visibility conditions in the portlets own code.
>
>
> I wasn't suggesting that. I was suggesting a model where separate
> applications didn't share the same layout for parts that were
> application specific.

they don't have too, you can switch the page (theme page) just like you
switch perspectives ..
pages and perspectives are orthogonal, they have to be combined but the
combination is not determined in advance.

the combination of 2 orthogonal concepts is worth a lot in terms of
productivity. It is like the separation of form and content.

>
>> the assumption is that portlet visibility is not a propriety of
>> *individual* portlets, but this is something that is related to some
>> activity of the user, or some usage context.
>
>
> This implicit assignment of portlets to slots worries my, both from
> the point of implementation complexity and understandability.

For the user this could not be simpler in terms of UI. This is how
newspaper CMSs work already, cf Polopoly (www.polopoly.se) used in many
Swedish sites (cf. www.dn.se, www.svt.se) There are templates with slots
(equivalent of pages in cpsskins) and there are sets of portlets
assigned to slots. The perspective in Polopoly for each slot is even
written using URLs,  you can change it directly in the URL. In the end,
and this is where I'm trying to get at: a site is a combination of pages
and perspectives (the two notions being 100% orthogonal)

when it comes to the implementation, I don't see how saving portlets in
folders is better. I still don't understand how you can have 10000 users
add portlets inside a same slot and manage portlet order easily.


>
>> I think that Eric summarized this quite clearly in his blog:
>>
>> """
>> What for ?
>>
>> Imagine that when writing a new component, you also can easily define
>> perspective. Let's take an example : a blog application. Well you can
>> define a "Blog Perspective" that would be activated when accessing to a
>> blog and that would arrange the portal to offer a "blog view" putting
>> portlets in right places. WIth this and the whole CPSSkins machinery, it
>> would be very easy to define interfaces that can adapt to user's
>> activity.
>> The same approach would also work for webmail, calendar, collaborative
>> work, personal portal dashboard, etc. The application would then only
>> define portlets and perspectives (no more pages, view, whatever :-).
>>
>>> From the user point of view, it would really improve the usability and
>>
>> how it the portal can adapt itself to his need. The user would also be
>> albe to define its own perspectives (like it's dashboard) and switch
>> between them.
>>
>> It would be new approach in the design of web applications, that would
>> allow to think them as user-oriented applications and not as a chains of
>> html pages.
>>
>> """
>>
>> The idea is to move away from the website approach to designing web
>> applications, with the endless poliferation of templates and macros. I
>> fully agree though that this is a change from the page / vi
>
>
> You seem to allow only two choices: perspectives and very low-level
> HTML/CSS/ZPT.  We're all in favor of page composition that allows
> pages to be assembles in various ways by various users.  I'm having
> a hard time buying the benefits of the approach you are suggesting
> over other high-level approaches.
>
> Here's what I think you are proposing:
>
> - Different components should appear in the o-wrap of a page
>   depending on the task being performed.
>
yes, this is the case with 90% of all web applications already.

> - The control of the portlets displayed in the o-wrap
>   should be controlled by a mode called a "perspective".
>
yes, or preferably the main content well should delegate the
responsibility of displaying content to the application underneath (cf
zope3 views), unless a set of portlets is more appropriate.

> I think this could be a good approach for some applications.
>
> I'm not convinced that varying the o-wrap by task is a
> good idea for all or even most sites.  If I did want to do
> that, I might prefer to do so by actually using different
> o-wraps (master pages) for different tasks.
>
this is not what I'm proposing either, in this case the view / adapter
approach is more suited. I mean: use portlets in the content well when
it makes sense, i.e on a portal page for instance where the content
consists of a collection of portlets.

> Don't get me wrong, I think the perspectives idea has a lot
> of merit.  I want it to be optional though.
>
the number 1 reason why I want to switch to perspectives is because the
"save-the-portlets-in-the-local-folder" approach has already cost us a
lot of time to implement, and because there are a lot of nasty side
effects that we didn't think of when we implemented this 1.5 year ago.
Containment is not suited for everything... It is perfect for tree-like
structures ( folders, themes, ) but not for local portlets.

Today I am convinced that moving all the local portlets into a central
portlet store and using the slots' display as some sort of proxy is
*much* better (using relations).

> I'll summarize my thoughts in a response to your original
> posting.
>
> Jim
>
yes

/JM