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] Event distribution question



And in order for the "AJAX code" to properly handle this for the entire page, the framework for it needs to be supplied by the Consumer rather than the portlet ...

I think these are the sort of traps one can easily fall into with partial solutions outside of a roadmap for the complete solution. That is why I would not want to put anything into v2 without a thorough discussion of how to provide complete support. On the more limited question as to whether a Consumer could do such a thing and still be conformant to the spec, I think you are ok. But as Mike points out, the user experience may not be all that it could be.

Rich



Michael Freedman <michael.freedman@oracle.com>

02/01/06 05:07 PM

To
Subbu Allamaraju <subbu@bea.com>
cc
Rich Thompson/Watson/IBM@IBMUS, OASIS WSRP TC <wsrp@lists.oasis-open.org>
Subject
Re: [wsrp] Event distribution question





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


---------------------------------------------------------------------
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]