Re: [wsrp] Clearification: Resource URLs and markup params, etc.

[Rich Thompson <richt2@us.ibm.com>]

We should be careful to do a full look
at this question as well as the deeper dives into particular sub-questions.

As to modes & windowstates, the
spec is relatively clear as to what these are. Section 6.9 has the following
relative to modes (6.10 has the equivalent for windowStates):
"They
are referred to as modes and should be thought of as how the Consumer is
managing the interaction with the End-User. Portlets may request mode changes
either through parameters on a link that an End-User activates or by returning
a newMode in a BlockingInteractionResponse. The Consumer MUST respect requests
to change the mode outside of exceptional circumstances (e.g. access control
restrictions), but the Portlet must not depend on such a request being
respected.

During getMarkup, handleEvents and
performBlockingInteraction invocations the Consumer indicates to
the Portlet its current mode via the MarkupParams
data structure"

I read this as stating that mode refers to how the Consumer is presenting
the Portlet's markup to the End-User. The Portlet has two opportunities
to request changes with the Consumer encouraged to respect such requests
whenever it can. However, in all cases the value sent in the MarkupParams
data structure MUST be the one the Consumer is actually using.

As to Title (i.e. the preferredTitle
field), the key for me is that only the Consumer knows how this is being
used (if it is used at all) and, from a WSRP protocol point of view, the
Consumer is not involved in any client-side processing as a result of resource
url activation. As a result, no matter how the title is used, the Consumer
can not update its representation of the title's value. However, we place
no requirement on the Consumer to use this value and therefore do not need
to make any special comments relative to returning it in a response from
getResource.

As to session, I agree that getMarkup
already introduces the problem of a late notification that a new session
now exists. What would people think about adding text to 6.1.13 (MarkupResponse
definition) describing how a stateless Consumer would need to write any
new session information to a cookie since it is likely too late to place
that information onto all URLs within the page (I suppose the other option
is to require Consumer URL rewriting and delay all rewriting until responses
have been received from all Portlets ... I would not favor describing this
option in the spec)?

Just to not loose potential spec changes
suggested so far (does this list miss any??):

1. Clarify difference in the semantics of getMarkup and getResource: Consumer request related to page aggregation vs client request related to need for additional information.
2. Add sentence(s) to MarkupResponse.sessionContext (6.1.13) describing how a stateless Consumer can handle such late knowledge of a new Portlet session.
3. 6.9/6.10 should note that HandleEventsResponse can also return newMode and newWindowState (see above quote from 6.9).

Rich

Richard Jacob <richard.jacob@de.ibm.com>

02/21/06 06:04 AM

To	Subbu Allamaraju <subbu@bea.com>
cc	WSRP TC <wsrp@lists.oasis-open.org>
Subject	Re: [wsrp] Clearification: Resource URLs and markup params, etc.

Subbu Allamaraju <subbu@bea.com> wrote on 02/21/2006
05:50:37 AM:

> >       - wsrp-mode and wsrp-windowState portlet
url parameters. I would
> > note the descriptions of these explicitly state that they apply
to
> > render and blockingAction urlTypes. I think maintaining the integrity
of
> > the aggregated page requires that these not be supported on resource
> > URLs, unless someone can point out how a Consumer's decorations
could
be
> > changed or how it would actually place a Portlet into maximize
> > windowState as a result of a resource URL activation.
>
> My interpretation is that, these parameters apply to the portlet
> processing the request, and not necessarily to the consumer applying
> decorations to the markup returned. When a URL contains a parameter
with
> a specific window state, the consumer is merely asking the producer
to
> generate markup or resource reflecting that window state. I don't
see a
> requirement in the spec to change the window state or mode of the
> portlet, although that's what typical portal-consumers may do.
>
huh?
We explicitly say that an URL invocation of a render/pbia URL includes
the
request to change the mode/window state.
Therefor I would say the contrary: Consumers should honor this (or be
strongly advised to do so) otherwise
the user experience will suffer. It seems strange for me to ignore the
request. I mean we're trying to define a common aggregated UI behavior
and
this certainly contradicts it.

> >        - title: This is another case of the
Portlet having opportunity
> > to impact the Consumer generated portion of the page during page
> > aggregation and therefore doesn't apply to resource url processing
>
> I think, this interpretation is specific to what the consumer is doing
> with the markup or resource. If the consumer is aggregating the response
> into a page that has windows-like titlebars, it might use the title
in
> the manner you suggest. Other usages of this field are possible. For
> example, a special purpose consumer may be displaying resources in
popup
> browser windows, and use the title in the browser title bar.
>
> >        - sessionID: I am willing to debate
this one as I can see a
> > number of good use cases for the Portlet returning a new session,
but
> > how a stateless Consumer could handle it is important.
>
> I agree that the stateless consumer use cases break down with sessionID
> returned from getMarkup or getResource. As Mike points out, we have
this
> problem with getMarkup itself.
>
> > In summary, perhaps we need to more explicitly state the semantic
> > difference between these operations. Do people generally agree
with the

> > semantics I have described above? Do people have other proposals
which
> > keep the stateless Consumer supported? Are people willing to
throw out
> > the stateless Consumer design point statements?
>
> Is it impossible to keep the consumer stateless? Perhaps not. To be
> truely stateless, consumer can't just push various pieces of state
into
> the markup when the page is getting generated on the server side and
> expect the state to ramain constant.
I think currently they can because the render result is a result of the
Consumer processing. Therefor the Consumer has the control.

> IMO, consumers will have to rely on
> browser side gimmicks to support state updates that happen after the
> page aggregation started (with getMarkup), or even much later (with
> getResource).
Well, things brings us again to AJAX style.
But this breaks the "rule" that the Cosumer is in control and
that the page
state is opaque/mainted by the consumer.
Now you seem to imply that portlets/resources can manipulate the overall
page state. I think this isn't true with what WSRP defines today and to
enable that we would need to drop some level of opaqueness of the overall
state.

>
> Subbu
>
> >
> > Rich
> >
> >
> > *Subbu Allamaraju <subbu@bea.com>*
> >
> > 02/15/06 11:48 AM
> >
> >
> > To
> >    WSRP TC <wsrp@lists.oasis-open.org>
> > cc
> >
> > Subject
> >    Re: [wsrp] Clearification: Resource URLs and markup
params, etc.
> >
> >
> >
> >
> >
> >
> >
> >
> > The issue of a producer returning two sessionIDs in parallel
requests
is
> > possible, and I don't know if the spec can help either the consumer
or
> > the producer.
> >
> > One way of avoiding returning new sessionIDs is to somehow tie
> > initCookie with sessionIDs, and raise InvalidCookie fault when
there is
> > a need to return new sessionID. It is possible to design a producer
to
> > tie init cookies to sessions, and never return sessionIDs.
> >
> > We have had a number of discussions on this topic in the past,
and the
> > solutions are not always pretty.
> >
> > Subbu
> >
> > Stefan Hepper wrote:
> >  >
> >  > Subbu Allamaraju wrote:
> >  >> On the question of modes and states, I don't see
why a portlet
should
> >  >> not specify mode and window state params on a
resource URL. The
> >  >> resource generated may depend on the window state
and mode.
> >  >>
> >  >> The real question is whether the mode and window
state specified in
a
> >  >> resource URL applies to  subsequent getMarkup/pbia/he
calls or not.
> >  >> The spec leaves this open. It also leaves the
same question open
for
> >  >> normal action and render URLs.
> >  >>
> >  >
> >  > right, I think that needs to be clearified.
> >  >
> >  >> On your point on session, the question is not
whether a portlet can
> >  >> return a new sessionID or not, but how it relates
to the sessionID
> >  >> returned via a getMarkup/pbia/he. If a producer
chooses to return a
> >  >> new sessionID, I would expect the consumer to
use that in
subsequent
> >  >> calls. This is because, from the consumer's point,
getResource is
just
> >  >> another request for a portlet.
> >  >>
> >  >> I can see at least one use case for returning
a new sessionID. That
is
> >  >> when a portlet is generating the resource, e.g.
to generate some
> >  >> response for an Ajax request. It should be able
to create new
session
> >  >> either when there is no session currently, or
when the current
session
> >  >> expired.
> >  >>
> >  >
> >  > what happens if you make a parallel render call in
that case?
Shouldn't
> >  > the spec that in that case that the session id returned
by both
calls
> >  > must be the same (like in the JSR 168 case where different
portlets
of
> >  > the same web app can create a new session in parallel
at render
time)?
> >  >
> >  >> On the question of title, my interpretation is
that the title
returned
> >  >> via any operation applies to the current markup
returned, and it is
up
> >  >> to the consumer to treat it as a new title replacing
the current
one,
> >  >> or use it just for that rendition of the markup/resource.
So, I
don't
> >  >> an issue.
> >  >>
> >  >
> >  > Still sounds confusing to me that the spec states
for title:
> >  > " The title the Portlet would prefer to be used
in any decoration of
the
> >  > markup."
> >  > what are decorations for resources?
> >  >
> >  > Stefan
> >  >
> >  >> Subbu
> >  >>
> >  >> Stefan Hepper wrote:
> >  >>> Subbu Allamaraju wrote:
> >  >>>> Stefan Hepper wrote:
> >  >>>>> I've some questions regarding the
resource URLs. From the
current
> >  >>>>> version of the spec it is not clear
to me how getResource and
> >  >>>>> getMarkup relate to each other.
> >  >>>>> - What happens if I specific new nav
params, new portlet mode /
> >  >>>>> window state on the resource URL?
Will they be valid for the
next
> >  >>>>> getMarkup call?
> >  >>>>
> >  >>>> Should they be? I think the semantics
are the same as that of a
> >  >>>> render URL.
> >  >>>
> >  >>> Depends if we say that getResource and getMarkup
are related or
not.
> >  >>> I think they they should be related and that
there should be only
one
> >  >>> set of portlet mode, window state, nav params,
per POP. I also
think
> >  >>> that we should not allow a resource URL to
change this state, that
> >  >>> doesn't make sense to me.
> >  >>>
> >  >>>>
> >  >>>>> - What are the semantics for portlet
mode and window state when
> >  >>>>> rendering a resource? What portlet
mode and window state will
the
> >  >>>>> portlet receive if nothing is specified?
> >  >>>>
> >  >>>> I would assume that this is up to the
resource handler or the
> >  >>>> producer or portlet.
> >  >>>>
> >  >>>
> >  >>> You mean that the result may be different
per mode or window
state? I
> >  >>> can see use cases for this, but think that
the spec should state
that
> >  >>> the getResource calls gets the current portlet
mode and window
state.
> >  >>>
> >  >>>>> - Can you specify navigational state
on a resource URL? (yes I
> >  >>>>> assume based on the current spec)
> >  >>>>
> >  >>>> Yes
> >  >>>>
> >  >>>>> - Why can the getResource call create
a new session?
> >  >>>>
> >  >>>> It might, if the consumer does not include
the current sessionID.
> >  >>>>
> >  >>>
> >  >>> Why would a getResource call need to create
a session? What would
be
> >  >>> the use case?
> >  >>>
> >  >>>> Could you elaborate on why you think getResource
and getMarkup
are
> >  >>>> not related. As far as the context provided
by the consumer is
> >  >>>> concerned, they are similar. The only
difference is on the
semantics
> >  >>>> of the response.
> >  >>>>
> >  >>>
> >  >>> When reading the spec again I could not find
a sentence saying
that
> >  >>> they are related. I think this needs to be
clarified.
> >  >>>
> >  >>> Another thing I noted is that the getResource
operation is allowed
to
> >  >>> change the portlet title. I think that does
not really make sense.
> >  >>> What is the use case for allowing to change
the title in
getResource?
> >  >>>
> >  >>> Stefan
> >  >>>
> >  >>>> Subbu
> >  >>>>
> >  >>>>
> >  >>>
> >  >>>
> >  >>>
> >  >>>
---------------------------------------------------------------------
> >  >>> To unsubscribe from this mail list, you must
leave the OASIS TC
that
> >  >>> generates this mail.  You may a link
to this group and all your
TCs
> >  >>> in OASIS
> >  >>> at:
> >  >>>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >  >>
> >  >>
> >  >>
---------------------------------------------------------------------
> >  >> To unsubscribe from this mail list, you must leave
the OASIS TC
that
> >  >> generates this mail.  You may a link to this
group and all your TCs
in
> >  >> OASIS
> >  >> at:
> >  >>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >  >>
> >  >>
> >  >
> >  >
> >  >
> >  >
---------------------------------------------------------------------
> >  > To unsubscribe from this mail list, you must leave
the OASIS TC that
> >  > generates this mail.  You may a link to this
group and all your TCs
in
> >  > OASIS
> >  > at:
> >  >
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS
TC that
> > generates this mail.  You may a link to this group and all
your TCs in
OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> > ---------------------------------------------------------------------
To
> > unsubscribe from this mail list, you must leave the OASIS TC
that
> > generates this mail. You may a link to this group and all your
TCs in
> > OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your
TCs in
OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php