[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]