Jean-Marc Orliaguet wrote:
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
Yes, I think that Rob mentionned that there was such a use case where
you had customers who wanted to control the way portlets were disposed
on the screen on an individual basis.
This gets to a terminology problem. JSR 168 defines portlets to
mean something quite different. In particular, JSR 168 specifies
portlets that are used by end users, by which I mean the final users,
as opposed to content managers, of a site to control what they
personally see on a site. This is what Rob was refering to.
(BTW, we would prefer that the term "portlet" be used to talk
about portlets as defined by JSR 168.)
Your local portlets are used by content managers to define
content to appear in the o-wrap, based on site location.
no, they are used by end-users as well -- this is already the case in
the Zope2 version of cpsskins -- inside the perspective that they have
permission to work in.
I'm talking about end users who don't have permission to work on any
part of the site. Further, when users's manipulate JSR 168 portlets,
they only effect what *they* see, not what others see. The goals
are very different.
this is where I don't understand how you can with a view / adapter /
page template paradigm get the JSR 168 portlets to fit in. Views,
adapters are for programmers, not for end-users, not even for content
I don't know what you mean. You can implement a JSR 168 pertlet system
in a variety of ways, including with adapters, views, ZPT etc. I wasn't
talking about implementation strategy. I was talking about the kind of
application -- the nature of the user interaction.
it depends on what the content well looks likes, if the content well
consists of 6 portlets, side by side or one below the other, then this
is not a problem to let the cpsskins layout mechanism take care of that.
I'm still not sure about what you put inside the content well, this is why.
if the content well contains a document with some advanced layout and a
lot of widgets then this is outside the scope of the cpsskins layout
We have applications that layout the content well using a content-reuse
paradigm. Here, users slot content and then specify how it
should dispayed. The point is that the paradigm is very different
from site layout. There are different users with different goals.
what do you mean by "complex"? have you seen the prototype? for a user
it does not seem too complex:
- choose a perspective
- add portlets to it
- assign the perspective to some context
- It's not clear what impact they have on URLs. If, for
example, perspectives are set via cookies or session
data, then both bookmarking and caching become more complicated.
what about skins?
- By introducing modes, I worry that they will make it
harder to talk about and teach systems build with them.
what should we say about skins then? they introduce exactly the same
"problems". However they exist in Zope3.
a perspective is a skin but for the portlets in a page. If you think
that perspectives are too complex then the skins mechanism should be
Perspectives are used in exclipse muc the same way we use views in
Zope 3. They are much more akin to Zope 3 views than to skins.
People will change perspectives often, but they will rarely change
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