Re: [wsrp] Redirecting from handleEvents

[Rich Thompson <richt2@us.ibm.com>]

I would agree that there are a set of
conflicting requirements for doing things correctly regarding redirecting:

1. From the portlet developer's point
of view, things are much easier if pbia is simply a special case of handleEvents.
This especially becomes true once the processing begins invoking core application
logic.
2. The current semantics of redirectURL
don't map well to concurrent handleEvent invocations.
3. A difference in the semantics of
redirectURL will be confusing to all parties.
4. Agreeing on a change in semantics
(with appropriate vetting inside all of our companies) within our target
timeframe will be next to impossible.

I see this leading to a couple of possible
courses of action:
1. Delay our timeline another month
or so and seek to resolve this issue in that timeframe
2. Seek to resolve our other open discussion
threads by next Thursday, start the 60-day public review period, agree
that at least one of our colleagues will submit a comment in this area
and then work on solving this while the public review is ongoing. This
would require we do an additional 15-day public review, but that may have
a smaller overall impact on the timeline than option #1.

Rich

Michael Freedman <michael.freedman@oracle.com>

07/12/05 02:19 PM

To	wsrp <wsrp@lists.oasis-open.org>
cc
Subject	[wsrp] Redirecting from handleEvents

We have been discussing whether to allow portlets to return
a redirect from a HandleEvents.  The agruments favoring this say its
symmetric and hence clearer/more understandable plus it gives the portlets
the full range and function of a performBlockingInteraction.  I.e.
if a PBI is merely a special event that is URL encodable/user invokable,
why aren't they functionally the same?  The current proposal we are
considering is:
Treat a redirect less like a a portlet Mode change request
and more like a portlet Window State change request.   I.e. currently
consumers receiving a redirect from PBI treat this much like a Mode change
request -- they honor it except for exceptional circumstances.  If
the semantics change to be more like Window State change requests the consumer
would only be asked to honor the request if it makes sense in its curernt
context.  By making this change handleEvent redirect can now be described
-- as the consumer has the rights and responsibilities to decide what makes
sense.  Note:  another implication of this proposal is that redirect
would no longer be a mutally exlcusive return value as we would want the
portlet to be able to return the appropriate state/information for the
consumer to use if it decides not to redirect.
For me, the key to deciding on this change lies in this
shift away from mutual exclusion.   With mutual exclusion we by and
large limit the redirect use case to allowing form data to impact a portlet
calculation in determining the redirect URL.  Internal state changes
are discouraged because new session ids/etc. can't be returned.  If
we don't believe you can rely on internal state changes it seems unlikely
to me there is a need to propogate events to other portlets to effect a
coordination.  As I don't recall us receiving feedback that we needed
to extend the semantics of redirect in PBI I don't think we should arbitrarily
do so now merely to be more symmetric with HandleEvents.
     -Mike-
---------------------------------------------------------------------
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