[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Redirect from handleEvents
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]