[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Request scope support
The nature of request scope in JSF is its active for both the action and
render stage. At question here is whether wsrp events will be modelled
as something that occurs between the action and the render and hecne
needs to stay in scope or implies a new JSF action and hence implies a
new scope. I think it is just as reasonable [in fact more reasonable]
to model the former then the later and hecne think its premature to
assume that event=new lifecycle like action=new lifecycle from the JSF
perspecitve.
-Mike-
Stefan Hepper wrote:
> 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
>>
>>
>
>
>
> ---------------------------------------------------------------------
> 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]