Re: [wsrp] Redirecting from handleEvents

[Subbu Allamaraju <subbu@bea.com>]

As you noted below, (1) is the main motivation from bringing this up. 
Similar semantics between handleEvents and pbia would help provide 
simpler APIs to portlets for event processing.

So far the main objection I have heard from some members in the group 
was about (2). As we debated last week, at a conceptual level, the issue 
is no different from, say, window state. I think a simpler change would 
be to add redirectURL to the response and keep it mutually exclusive. 
This way, we will still be able to maintain consistency, a simpler 
programming model, and account for similar use cases.

I agree on (3) and (4). Moreover, changing semantics of pbia invites a 
bigger challenge as it would break backwards compat at a semantic level.

Regards,
Subbu



Rich Thompson wrote:

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