[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp] Request scope support
We work in a similar fashion to what Subbu is indicating working with session and navstate, allowing variations, to allow the portlet developer to manage what works best for the application during that lifecycle. For example the gm() can return the cached markup from the pbia() or he() in many cases while navstate is the same. In other cases the a re-execute of the page would be necessary to present real-time data. The re-execute would happen with any applicable data required such as navState, pbia and event data, this re-execute should not cause any events or change/add/delete data from say a database...ie adding a record to table again as it would in the pbia(). As Subbu, says there is an impedance mismatch with this type of page-oriented technology. - Mike -----Original Message----- From: Subbu Allamaraju [mailto:subbu@bea.com] Sent: Thursday, January 19, 2006 9:25 AM To: wsrp@lists.oasis-open.org Subject: Re: [wsrp] Request scope support Based on our call yesterday, it is not clear yet if we need a new solution and whether the current proposal would solve the problem. Taking the validation error example, let's say the producer wants to render the error messages till the next action or event. a. pbia: Producer receives data that fails validation. Producer returns new navState that encodes validation errors. b. Several getMarkups: Producer renders the errors based on the navState. c. he: Producer receives the current navState. But since a new event is handled, Producer clears the previous messages, and starts processing the faces app. If it encounters new errors, the Producer will encode the same in new navState, and returns to the Consumer. Producer may also choose to discard the events and keep the current validation messages in the navState. d. he: Producer receives another batch of events. Same as (c). e. Several getMarkups: Same as b. e. pbia: Cycle begins again. Same as a. Given this, if the use case is to render the same validation messages till the next pbia or he, the Producer can use the navState to render appropriate messages in the markup. In BEA's implementation, the Producer stores this data in a session, but maintains it for the lifetime of the navState (i.e. till the next he or pbia). But if the use case is to render the messages for just one or a few (but before the next pbia/he) getMarkups, the navState would not work. But I have not heard that this indeed is the use case. Regards, Subbu Rich Thompson wrote: > > What I heard on the call yesterday was that this scope could at least > be mostly dealt with by Producer implementations supporting such a > scope, but that there may be times when Consumer assistance would make > a difference. Consider some of the more complicated scenarios (note, > these are common): > > 1. pbia() > 2. he() > 3. he() > 4. gm() > 5. gm() > 6. gm() - different navState > > As I typed the ID proposal, it became clear having the Consumer > differentiate that step 6 starts a new User Request Cycle would be > expensive (it requires the Consumer "remember" the most recent > navState separately (especially if templates are in use), or at least > process URLs in a manner that recognizes the URL has a different > navState). If one throws in the bookmark/back button issue, the > Consumer would have to actually store the last navState used in order > to determine whether a new ID was required. I thought this would be > too expensive of a requirement. > > On the flip side, the Producer can't tell whether a new User Request > Cycle starts between steps 1 & 2 above due to the possibility that > markup was served from a cache. > > I tried to develop the boolean flag approach as a middle ground where > the burden of managing this scope stays at the Producer, but the > Consumer provides a simple indicator of times when it knows a new User > Request Cycle has started. This can help the Producer determine > whether steps 2 & 3 are in the same cycle as step 1, but leaves the > thornier problem of step 6, bookmarked URLs and the back button to the Producer. > > Rich > > > *"Mike Caffyn" <mike@netunitysoftware.com>* > > 01/19/06 08:20 AM > > > To > <wsrp@lists.oasis-open.org> > cc > > Subject > RE: [wsrp] Request scope support > > > > > > > > > Sorry I also missed the call, I agree with Richard and Andre. It seems > the producer/portlet should be able to handle this request cycle > without the consumer providing help. In normal operations the portlet > would that either the request cycle started with a pbia() or he() and > can reload that information during the render or be able to work with > stored cache from the > pbia() or he(). As Andre points out this method could run into > problems during networking related issues, but due to optional nature > of many interfaces/action/reactions in wsrp this could effect any type > of portlet depending on the consumer. > > For example an complex request lifecycle to a portlet may have been: > > 1. Pbia() > 2. He() > 3. He() > 4. Render() > > If the pbia() fails due to networking problems I would assume this > would be reported and the user would re-execute? If either 2 or 3 he() > fails the user would be non the wiser and the render would happen as if no event happened. > If the render() fails, the consumer may use cache to display the > previous markup? There seems to be lots of areas where the page could > be inconsistent. Does refreshing the page cause the lifecycle to happen again? > > I'm not totally sure I understand the issue with the back button and > bookmark in relationship to lifecycle and adding helper id. > > -Mike > > -----Original Message----- > From: Richard Jacob [mailto:richard.jacob@de.ibm.com] > Sent: Thursday, January 19, 2006 7:14 AM > To: wsrp@lists.oasis-open.org > Subject: Fw: [wsrp] Request scope support > > I think the current proposal strenghtens my arguments I made yesterday. > It's not quite easy to implement such a message correlation on the > consumer side and the value it gives seems quite limited to me. > We seem already to have troubles to clearly define what such a cycle > would be, what it would mean and at the same time keep the features > that WSRP and > JSR168 offers in terms of bookmarkability back button support, etc. > If we defined the requestCycle flag what would the difference really > be in letting the Producer set internally flag (without the protocol > need to transfer it). The Producer can easily conduct the same > information on the incomming request, i.e. if a pbia() or he() occurs > on a portlet instance (use the portletInstanceKey here) then it can > consider it a new request cycle. > I don't see the value in the protocol support to mimic this behavior. > > Unfortunalty JSFdoesn't fit well into our model simply because it > doesn't clearly seperate action processing from rendering. > Now we seem to try to "retrofit" our protocol in such a manner that it > can act as a single phase protocol. > I think consequently this might break our intended behavior which we > might not have foreseen yet, examples here are cachability, back > button, bookmarks. > > 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@lists.oasis-open.org > 01/18/06 11:09 PM cc > > Subject > [wsrp] Request scope support > > > > > > > > > > > > For those not on the Interfaces SC call today, the use cases regarding > Producers who have a concept of a user-request scope needing some > support from Consumers was discussed. There was a building consensus > toward having the Consumer supply an ID which changes only on action > or event processing, though most wanted to see a proposal in the > context of the spec and think through what the impacts of those > changes would be on reasonable Consumer implementations before > deciding whether or not to include such support in v2. I agreed to > draft such a proposal, but had a problem with the scenario of a > End-User jumping to a different state of the page. This can easily > happen via a bookmark, but also may happen when the browser's back > button is pushed. This caused me to change the proposal to a style > where the Consumer indicates to the Producer when it knows a new > requestCycle is starting via a boolean rather than being more > definitive by supplying an ID. I left the original attempt in (with a strike through the text) so that people can easily consider that option as well. > > > > Rich [attachment "RequestID_proposal.doc" deleted by Richard > Jacob/Germany/IBM] > --------------------------------------------------------------------- > 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]