OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]