Re: [wsrp] Event distribution question

[Michael Freedman <michael.freedman@oracle.com>]

The key here Subbu is you say that the consumer decides to not render 
other portlets in this request.  Personally, however, I think its not 
the most obvious consumer implementation style  --  a page reload will 
now cause the event distribution and hence potential state 
change/different UI results  which could surprise the user.  Also if 
this event was instrumental in keeping the page coordinated this 
coordination is lost until the next reload/request.  Again I am not sure 
the most desired consumer behavior.  If the consumer tries to give the 
user a consistent behavior [because of course the user doesn't know 
whether client side programming is being used] it would account for 
resolving the event chain and rendering all the portlets that are 
affected and the AJAX code would properly deal with this.
     -Mike-

Subbu Allamaraju wrote:

>
> Just wanted to confirm this since this issue came up as we were 
> discussing events and Ajax at the JSR186 meeting. I've heard an 
> opinion that the spec does not allow the scenario below.
>
> Subbu
>
> Rich Thompson wrote:
>
>>
>> Especially considering that it is always a Consumer choice as to 
>> whether to dispatch an event at all, I would not consider the 
>> proposed Consumer behavior to violate the conformance statement. For 
>> me, the key is that the Consumer has finished dispatching events for 
>> the request cycle in which it is  gathering markup from the single 
>> portlet.
>>
>> Rich
>>
>>
>> *Subbu Allamaraju <subbu@bea.com>*
>>
>> 01/31/06 04:52 PM
>>
>>     
>> To
>>     OASIS WSRP TC <wsrp@lists.oasis-open.org>
>> cc
>>     
>> Subject
>>     [wsrp] Event distribution question
>>
>>
>>     
>>
>>
>>
>>
>>
>> Under the section that describes the "Three-step Protocol" (sorry - no
>> page numbers again), there is a conformance statement requiring that
>> consumers MUST NOT begin gathering the markup until it considers that
>> all portlets to have finished the event distribution step.
>>
>> I remember the background on this statement, but need some clarification
>> on how to interpret this in the context of a specific implementation
>> scenario.
>>
>> Here is my use case:
>>
>> - Consumer is rendering a portlet in a different browser request, either
>> by using an iframe, or through some DOM manipulation via Ajax.
>>
>> - Portlet has an action URL.
>>
>> - Portlet fires an event during this action processing. This event can
>> only be handled by some other portlet.
>>
>> - Consumer looks at the events, but since it is not rendering other
>> portlets during the same user request, decides to batch the event for a
>> future delivery. When the user requests the aggregated page sometime
>> later or when the target portlet is being rendered via another request,
>> the consumer decides to dispatch the batched event to that portlet, and
>> render those.
>>
>> This flow also ties into the use cases I brought up for using Ajax in
>> portlets. I can hear arguments that this opens up state management
>> issues, but I would argue that this is a consumer's issue and the spec
>> should not care whether the aggregation is done in the same request or
>> across several requests.
>>
>> I can see two possible interpretations of the statement, one of which
>> makes the above scenario not comply to the spec.
>>
>> 1. Consumer considers that there is only one portlet being processed in
>> the current request, and decides that event distribution is over. Here
>> "all" implies just one portlet, and hence is complying to the spec.
>>
>> 2. Consumer is rendering a portlet before dispatching the event, and
>> hence is violating this conformance statement.
>>
>> What do others think?
>>
>> Regards,
>> Subbu
>>
>> ---------------------------------------------------------------------
>> 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