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
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
|