RE: [wsrp] Request scope support

[Rex Brooks <rexb@starbourne.com>]

As a consumer, I'd like to have a way for  JSF to work seamlessly in 
WSRP, but I am not sure we are going to be able to arrive at a good 
solution for v2.0. For my end users, I would also like to have a more 
narrow back button for the portlet, or set of portlets which share 
state without having the whole page involved, but I understand that 
that becomes highly problematic if a portlet gets maximized, as well 
as with other possible state changes.

Rex

At 8:20 AM -0500 1/19/06, Mike Caffyn wrote:
>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


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309