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


The problem I see with this is that it may result in different render 
results.
E.g. the portlet may have also nav params and if rendered together with 
the original portlet the nav param would be value A. When the portlet 
finally gets the event the nav param was changed in the meantime and is 
now B, and thus the portlet would render something differently.

Also, what would be the semantic if the portlet would issue a event 
based on the queued event? Given that transient properties and nav state 
may be different from the original request it does not seem logical to 
me to call this the same request as the original one.

Stefan

Subbu Allamaraju wrote:
> Rich Thompson wrote:
>>
>> 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 have not really explained how the consumer is addressing the problem. 
> I leave it to the implementation. There are ways to solve these 
> problems, like the one you mention.
> 
>> 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.
> 
> Right. Whether we do some additional things in the spec for V2 or not is 
> up to the TC. I just would like to note there is sufficient interest 
> among developers to use these techniques, and some consumers may have to 
> go through some paradigm shift or reorientation to align with browser 
> side aggregation/rendering techniques.
> 
> Subbu
> 
> 
>> *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
>>
>>
>> --------------------------------------------------------------------- 
>> 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]