[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Clearification: Resource URLs and markup params, etc.
FYI I had recently checked this: Section 10.2.1.5 and 10.2.1.6 are very explicit about where wsrp_mode and window_state are valid: The wsrp-mode portlet URL parameter MAY be used whenever the wsrp-urlType portlet URL parameter has a value of “blockingAction” or “render”. The wsrp-windowState portlet URL parameter MAY be used whenever the wsrp-urlType portlet URL parameter has a value of “blockingAction” or “render”. -Mike- Richard Jacob wrote: >What also strikes me in this context is that we seem to be ambigeous when >we're reusing our structures / url-rewrite-tokens. >I think we should have a more crisp definition on which structure >elements/members sense (or are even allowed) for which operation. >I would argue that this significantly helps developers in understanding and >implementing the same protocol without the possibility to (mis-)interpret >the spec in different ways. >So it's a tradeoff between protocol flexibility and protocol clarity. >One example here is the reuse of markupContext with getResource(). I don't >think that setting a new portlet title makes sense when delivering a >resource if we agree on Rich's semantical differentiation between >getMarkup() and getResource() - and I have the sense that we probably have. >The same issue is the window state and portlet mode in resource URLs. > >Reviewing chapter 10 it striked me that we don't clearly describe which url >parameters are allowed for which url-type (example wsrp-url in action URLs >makes definitly no sense). >I would therefor mandate to rewrite the BNF of our URL formats to clearly >denote which url params can be used for which url-type. Also I would >suggest to use BNF notation to denote mandatory and optional parameters. >I think this would also help developers to understand the semantics of the >URLs and their according operations better. > >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 > > > > Rich Thompson > <richt2@us.ibm.co > m> To > WSRP TC <wsrp@lists.oasis-open.org> > 02/21/06 05:21 PM cc > > Subject > Re: [wsrp] Clearification: Resource > URLs and markup params, etc. > > > > > > > > > > > >I agree with your general comments; Without having spent much time >reviewing this phrasing, I would think the clarifications would look >something like: > >- (6.1.13 - MarkupResponse): Since the MarkupContext structure could >provide a new sessionID after the Consumer has begun sending the page to >the End-User, special handling is required in order to not lose state >related to the new session. Even for stateless Consumers, there are >techniques to properly handle this issue (e.g. HTTP cookies). > >- (6.2 - getMarkup): This operation's semantics are that the Consumer is >aggregating a page which includes the Portlet's markup. > >- (6.3 - getResource): This operation's semantics are that the client has >requested additional information in a manner that utilized the Consumer as >a proxy for supplying that information. > >Rich > > > Subbu Allamaraju > <subbu@bea.com> > > To > 02/21/06 10:12 AM Rich Thompson/Watson/IBM@IBMUS > cc > WSRP TC > <wsrp@lists.oasis-open.org> > Subject > Re: [wsrp] Clearification: > Resource URLs and markup params, > etc. > > > > > > > > > > > > > > > >>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)? >> >> > >Instead of mentioning specific implementation choices, how about >highlighting the fact that consumers must be ready to honor sessionID >changes getMarkup and getResource so that they can provide meaningful >user experience? > > > >>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. >> >> > >In principle, I agree, but would not want to make statements that limit >the use of getResource to static resources, or such requests to be >always driven by client requests after markup generation. The consumer >may want to pre-fetch resources. > > > >> 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. >> >> > >Agreed. > > > >> 3. 6.9/6.10 should note that HandleEventsResponse can also return >> newMode and newWindowState (see above quote from 6.9). >> >> > >Agreed. > >Subbu > > > > > >>*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 > > >--------------------------------------------------------------------- >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]