[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Clearification: Resource URLs and markup params, etc.
yep, and this again points towards a change of the BNF... ;-)
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Team Lead & Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
Stefan Hepper
<sthepper@hursley
.ibm.com> To
WSRP TC <wsrp@lists.oasis-open.org>
02/22/06 06:57 AM cc
Subject
Re: [wsrp] Clearification: Resource
URLs and markup params, etc.
and I would like to see a 4th one stating if, or if not, you are allowed
to set new portlet mode, window state, navigation parameters on a
resource URL.
Stefan
Rich Thompson wrote:
>
> 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
>
>
> --------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]