[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Request scope support
Mike, are you implying that handle event is stateful and depends on the order of action and render calls? Why would a he create different results if called within a client request or in the sequence you outlined below? I assumed that he is stateless and thus it doesn't matter if the he is called within the same client request or a different one. Stefan Michael Freedman wrote: > I think its premature to assume a HandleEvents = a new JSF action > lifecycle. If it does it implies the container or portlet (bridge) > transforms the event into the equivalent of an http post that the > current JSF view is expecting to deal with. I think this is too big a > reach for us to make. I can see other interpretations where this maps > entirely within the InvokeApplication phase of the lifecycle [or as a > step between invokeApplication and navigation -- say a Handle External > Events stage. The main point here is that JSR 286 potentially in > conjunction with JSF hopefully will clarify this. I am fine with us > waiting for this clarification before proposing wsrp changes to support > as long as we recognize the risk that it might take us another revision > to wsrp [3.0?] to support eventing for JSF built portlets. > > If we ignore HandleEvents, then we merely have wsrp 1.0 semantics > involving PBI/GM. In such circumstances I think its reasonable to > assume the producer can manage itself by stuffing a reference into > either navigational state or a transient session property. Its only > if/when a producer needs to dissembiguate whether a HandleEvents > occurred within an Action lifecycle or not may such guidance need to be > offered by the consumer. > -Mike- > > Richard Jacob wrote: > >> are you saying that 1 and 4 wouldn't be distinguishable? >> My assumption would be that he() would anyway trigger a new JSF phases >> request. In that case the cleanup would be necessary anyway. >> So the producer would be able to determine that. >> >> 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/19/06 04:50 >> PM cc >> >> >> Subject RE: [wsrp] Request scope >> support >> >> >> >> >> >> >> >> >> >> >> Consider the following scenario: >> >> 1. User activates an action URL -> pbia() on the Portlet >> 2. Markup served from something other than gm() - e.g. a cache hit or >> network failure >> 3. User activates an action URL on a different portlet >> 4. The other portlet generates events which get distributed to the >> portlet >> -> he() on the Portlet >> 5. Rest of the steps like the "normal" example >> >> From the user's perspective, there would be two request cycles, but the >> Producer is unable to determine this. >> >> I think I here you raising the question as to whether the Consumer can >> reasonably determine this such that the proposed flag could be set and >> whether anything would be gained relative to the Producer simply managing >> this scope entirely by leveraging things like navState. I'm not sure >> which >> path is better and would like other perspectives to comment on this as >> well. >> >> Rich >> >> >> Richard >> Jacob >> <richard.jacob@de.ibm.com> >> >> >> To 01/19/06 09:24 AM >> Rich >> >> Thompson/Watson/IBM@IB >> >> MUS >> >> cc >> wsrp@lists.oasis-open. >> >> org >> >> Subject RE: [wsrp] >> Request scope >> support >> >> >> >> >> >> >> >> >> >> >> >> Could you elaborate on "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 think I don't get your point here. How does cached content refer to the >> transition from 1 to 2? >> The consumer wouldn't present markup between 1&2 and both modify state on >> the producer, so potentially both would result in a new navState. >> >> My assumption would be that he() starts a new JSF phases cycle anyway so >> (because both modify state) so from the JSF's perpective, the request >> scoped beans would need to be reinitialized anyway. >> >> 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/19/06 03:03 PM cc >> >> Subject >> RE: [wsrp] Request scope support >> >> >> >> >> >> >> >> >> >> >> >> 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> >> >> To >> 01/19/06 08:20 AM <wsrp@lists.oasis-op >> en.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 >> >> >> --------------------------------------------------------------------- >> 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]