Redirecting from handleEvents

[Michael Freedman <michael.freedman@oracle.com>]

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-