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:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
