[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]