OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp] Redirecting from handleEvents


On the timeline noted below, I think it may be aggressive to expect to 
close all open issues and have the draft ready by next Thursday. I 
suggest we discuss this in the next TC call.

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 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]