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

[Jim Fulton]

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

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

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

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

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