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

[Jim Fulton]

Jean-Marc Orliaguet wrote:
> Jim Fulton wrote:
> 
> 
>>Jean-Marc Orliaguet wrote:
>>...
>>
>>
>>>This is what I meant with having a "unifying concept". And that sounds
>>>very unifying to me already.
>>
>>
>>Perspectives, if I understand how you are describing them, and how
>>Eclipse describes them,
>>http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html,
>>
>>are simple separate applications.  They are different ways of working
>>on content
>>based on tasks.  They could be provided with perspectives, or, more
>>simply,
>>with different collections of web pages, using different styles.  I
>>don't understand the benefit you think they provide nor do I see how
>>they unify anything.
> 
> 
> 
> 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.


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

> The main idea is to define visibility in a coherent way,

We're both in favor of that.


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

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

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

- The control of the portlets displayed in the o-wrap
   should be controlled by a mode called a "perspective".

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.

Don't get me wrong, I think the perspectives idea has a lot
of merit.  I want it to be optional though.

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

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