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