[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Redirect from handleEvents
But the point of redirect is to take the user outside the context of the consumer, provided the consumer is willing. Subbu Mike Caffyn wrote: > I think my concerns with the redirects is that the portlet is assuming > knowledge of the either the consumer or client and is really outside the > context of the current consumer aggregated page/application. So I agree > with > Richard and Mike this doesn't seem worthwhile until the portlets have more > knowledge of the consumer for navigation of pages. > > Regards, > Mike > ----- Original Message ----- > From: "Andre Kramer" <andre.kramer@eu.citrix.com> > To: "Richard Jacob" <richard.jacob@de.ibm.com>; "Michael Freedman" > <michael.freedman@oracle.com> > Cc: "wsrp" <wsrp@lists.oasis-open.org> > Sent: Wednesday, August 17, 2005 9:49 AM > Subject: RE: [wsrp] Redirect from handleEvents > > > A display that has multiple views (portlets) under the control of > another (a controller portlet) could have the user click in a view which > raises an event that causes the controller to detect completion and > re-direct to some other controller (with its own multiple views). My > example is a workflow that has sequential tasks with a re-direct used on > task completion. > > Regards, > Andre > > -----Original Message----- > From: Richard Jacob [mailto:richard.jacob@de.ibm.com] > Sent: 17 August 2005 13:23 > To: Michael Freedman > Cc: wsrp > Subject: Re: [wsrp] Redirect from handleEvents > > I agree with Mike and have the same concerns. > For me a redirect makes sense if the initially targetted portlet, i.e. > the > one the user interacts with sends a redirect (be it on an action or an > event) and the portlet is able to address yet another portlet on the > consumer page (or even another page). > But as of now we have only a simple "external" redirect that leaves the > Consumer portal context and we don't have an addressing scheme which > would > allow addressing of other portlets/pages. > Therefor I see very limited usage to redirect right now and I don't see > a > real valueadd in allow redirect in events for now. > Once we probably discuss more sophisticated redirect scenarion with > page/portlet affinity then redirect may make sense. > For the time being I wouldn't add this extra complexity to the protocol > without a real valueadd. > > 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:richard.jacob@de.ibm.com > > > > > Michael Freedman > > <michael.freedman > > @oracle.com> > To > wsrp <wsrp@lists.oasis-open.org> > > 08/04/2005 01:08 > cc > AM > > > Subject > Re: [wsrp] Redirect from > > handleEvents > > > > > > > > > > > > > > > > > > Subbu, > I continue to question the value of adding redirect from a > handleEvent > because I don't understand the circumstances where a Consumer would > honor > such a redirect. These are the possible situations I see: > A portlet's handleEvent is called after a user interaction in > another > portlet. > Why would a consumer allow/think its appropriate to redirect when > this redirect is caused not by the portlet being interacted with > but > something else in the page/context? > A portlet's handleEvent is called after an interaction in this > portlet that raised an event that got distributed to another > portlet > which raised an event that the originating portlet is now > handling. > Though slightly more credible because the portlet doing the > redirect > was the target of the original interaction it again seems suspect > that a Consumer [even if it bothered to pay attention to who was > the > original target] would allow such a redirect. Do you have a use > case > for this? Is this the one scenario you are concerned about? > A portlet's handleEvent is called by the consumer directly without > any user interaction. > Why would a Consumer allow/honor this? Redirecting without a user > interaction breaks the consumer in that a portlet can hijack a > page > and prevent all [regular] users from ever getting to that page. > -Mike- > > Rich Thompson wrote: > > While it is a reasonable exercise to make sure our web service > definitions map reasonably to popular platforms, lets make sure > not > to go too far in trying to define how something like the Java > Portlet > API should be extended to deal with v2 items such as events as > some > other standardization group will be who makes those > determinations. > > As to your questions: > a. As a user, I rarely see what looks like an action URL result in > a > redirect. On the other hand, I frequently see regular URLs direct > the > browser away from an aggregated page. > > b. I would hope APIs such as the Java Portlet API would support v2 > events by allowing developers to define their own event handling > methods and connect these to events via metadata (one could even > hope > for a reuse of WSDL!). This makes it easier to expose the > semantics > of the event handler to whomever is defining how the portlet is > participating in the processing of the aggregated page(s). This is > significantly more natural for the portlet developer than having a > generic method which is simple a large switch statement for > selecting > the "real" event handler. Whether of not such methods are required > to > have a specific signature or whether the available set of inputs > and > outputs is variable depends a lot on the environment, but > requiring a > specific signature style is not a significant burden on the > developer. > > Rich > > > > Subbu Allamaraju <subbu@bea.com> > > > > > > 07/29/05 05:46 PM > To > wsrp > > > <wsrp@lists.oasis-open > .org> > > > cc > > > > Subject > [wsrp] Redirect from > > handleEvents > > > > > > > > > > > > > > > > > > > > > To take yesterday's discussion forward, I would like to summarize > the > > current arguments. > > Problem: handleEvents does not allow Producers to request for a > redirect. > > Argument 1: To keep the programming model simple, allow Producers > to > return a redirectURL, and clarify that Consumers are NOT REQUIRED > to > honor such a redirect. > > Argument 2: Since some/most Consumers may not honor a redirect due > to > > the possibility of parallel event processing, why specify > something > that > may not work always. > > I would like to ask the following questions for discussion next > week. > > a. How frequently do developers rely on redirect? > > b. How would you see redirectURL getting exposed in the portlet > programming model, for example in the Java Portlet API. > > 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]