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