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