BTW, we did have similar issues when we implemented support for Struts
and Beehive Page Flows in BEA's producer.
Unfortunately, as you rightly pointed out, we are retrofitting these
modern page-oriented technologies into a multi-step protocol. There is
an impedance mismatch.
Subbu
Richard Jacob wrote:
> I second that.
> As said yesterday, the behavior we described would pretty much fit into
> "lifting" the request scope beans into the navState scope.
> The only negative I've heard is that the size of the request scope data can
> grow large. I guess this has to be verified and still the producer could
> decide that on its own.
>
> 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:
>
>
>
> Subbu Allamaraju
> <>
> To
> 01/19/06 03:24 PM
> cc
>
> 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" <>*
>>
>> 01/19/06 08:20 AM
>>
>>
>> To
>> <>
>> 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:]
>> Sent: Thursday, January 19, 2006 7:14 AM
>> To:
>> 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:
>>
>>
>>
>> Rich Thompson
>> <
>> m> To
>>
>> 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
>
