[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Clearification: Resource URLs and markup params, etc.
> 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. The spec only says that the MarkParams's state/mode value be changed to the one specified in the URL. > 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. The portlet cannot, in any case, change the state of what is outside the portlet's markup in an aggregated page. For the same of debate, let's assume that the consumer is composing the overall page, and every portlet it is trying to aggregate returned a new sessionID during getMarkup. The consumer will have some choices: a. Buffer all portlet's markup, compute state, and then rewrite all URLs pushing the same state into each URL. b. Buffer all portlet's markup, compute state, push the state somewhere in the DOM of the response page. Now, let's assume that a render URL caused a new getMarkup which then returned a new sessionID. The consumer can do one of the above, or trigger some client side script to update the state stored in the DOM with the new state. The consumer can even limit this to a delta of the state. In this example, the consumer is still in control of the page, but is prepared to be stateless. All I'm saying that there are ways to manage the state on the client side in such a way that the consumer need not lock the state of the page once it starts generating the page. Of course, consumer can always manage the state on the server side, which is much easier to implement for cases like this. Subbu > >> 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]