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