[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] [AJAX] Redirect behavior - clarification
I'm sorry, but I'm not seeing a clear justification for the suggested thinking. I'm trying to construct a clean behavior that is palatable to web developers, and I will reflect these points in the proposal I'm working on. We can follow up once we take it up for discussion. Subbu Rich Thompson wrote: > > It sounds like we keep loosing track of context, I think getting a draft > in front of us before pushing these discussions too far will help a lot. > The first draft may want to just be an outline of the issues & > resolution approach as it isn't worth working too many details when the > high level issues haven't been resolved. > > With that said; > I think there is a big difference between a portlet seeking to refresh a > fragment of itself (I would argue this needs to use a resource URL for > semantic reasons) and a portlet behaving in a manner that allows > Consumers to do partial page updates with the full semantics of action > and render URLs. Trying to blur the semantics between these two will > raise quite a few issues. If there is significant value in defining new > semantics somewhere between what we have now for action/render vs > resource URLs, I would first want to be convinced of the value and would > then prefer defining new urlTypes rather than blurring the current > semantics. Whether or not those new urlTypes can reuse current > operations/structures would be the next step in the discussion and so is > a long way from where the TC discussion at the F2F had agreement. > > Rich > > > *Subbu Allamaraju <subbu@bea.com>* > > 05/11/06 10:48 AM > > > To > Rich Thompson/Watson/IBM@IBMUS > cc > wsrp@lists.oasis-open.org > Subject > Re: [wsrp] [AJAX] Redirect behavior - clarification > > > > > > > > > That's an interesting argument, but I find it unnatural for developers > using XHR to fetch fragments. > > Here the portlet made the choice to use consumer-supplied XHR, and the > behavior the portlet dev would see must be consistent with what would > happen when a web dev uses XHR, and the resource redirects. When this > happens, the user does not see the new page, the XHR sees the new page. > I would argue that the same behavior must be honored when the same web > app is aggregated as a portlet. WSRP's redirect style only makes sense > only when the redirect response is sent to a full page request. What's > the point in imposing an unnatural redirect style? > > Subbu > > Rich Thompson wrote: > > > > The semantics of returning a redirectURL break when the redirect header > > is silently set on the XHR response. The semantics would be maintained > > if instead the server-side Consumer component communicated the redirect > > to the browser-side Consumer component which then redirected the entire > > page. > > > > I think the key point is that the protocol semantics have to be honored > > by the Consumer despite the splitting of its components across the > > network boundary. Requiring the entire system to be aware of, and adapt > > to, a particular deployment choice of the Consumer would introduce > > significant complexity without any offsetting value. > > > > Rich > > > > > > *Subbu Allamaraju <subbu@bea.com>* > > > > 05/11/06 12:55 AM > > > > > > To > > Rich Thompson/Watson/IBM@IBMUS > > cc > > wsrp@lists.oasis-open.org > > Subject > > Re: [wsrp] [AJAX] Redirect behavior - clarification > > > > > > > > > > > > > > > > > > Consider the following sequence: > > > > An event occurs in the UA > > -> Consumer-generated script sends an XHR to the Consumer > > -> Consumer sends a pbia request to the Producer > > <- Producer returns a redirectURL > > <- Consumer sends a redirect header back to the UA > > -> XHR will silently follow the redirect > > <- XHR obtains the response from the redirect source > > -> XHR invokes consumer's onreadystatechange function > > with the response > > > > Upon redirect, the script is still in charge. Also the fact that > > browsers follow the redirect silently (at least in the browsers I tested > > with) makes this case different from the normal redirect case, and > > requires the consumer's onreadystatechange function to handle the > response. > > > > Subbu > > > > Rich Thompson wrote: > > > > > > I don't see why the Portlet's callback function would ever get > called if > > > pbia() returns a redirectURL. The semantics of redirecting the user > > > applies to the page and so normally gm() is usually not invoked on any > > > of the Portlets. How the Consumer chooses to communicate this between > > > its server and browser components is an implementation decision, > but the > > > semantics for both the Portlet and End-User should be identical to the > > > server-side aggregation case. > > > > > > Rich > > > > > > > > > *Subbu Allamaraju <subbu@bea.com>* > > > > > > 05/10/06 01:16 AM > > > > > > > > > To > > > Rich Thompson/Watson/IBM@IBMUS > > > cc > > > wsrp@lists.oasis-open.org > > > Subject > > > Re: [wsrp] [AJAX] Redirect behavior - clarification > > > > > > > > > > > > > > > > > > > > > > > > > > > The context is a redirect response to an XMLHttpRequest for the > > > consumer-aided AJAX case. In this case, the redirect is handled at the > > > XMLHttpRequest level, and the consumer script that made the request > > > would receive the response from the redirect target. > > > > > > In non-redirect cases, the consumer can create the response > payload for > > > XHR requests, and it knows what to expect from the response. In the > > > redirect case, the consumer can assume that the response solely > belongs > > > to the portlet's callback. The more I think about this, this seems > > > reasonable. I'm just remarking that the consumer implementations will > > > have to handle this case. > > > > > > Subbu > > > > > > > > > Rich Thompson wrote: > > > > > > > > I'm sorry, but the context for your question appears to be > missing. I > > > > presume you are asking about a situation where the Consumer is > > providing > > > > some sort of client-side aggregation and that pbia() has returned a > > > > redirectURL. If that is your question, I do not see why the > semantics > > > > would be any different than it is today, namely that the > Consumer will > > > > redirect the End-User to the new URL. Are you proposing > changing this > > > > portion of the protocol's semantics, or that moving the network > tier > > > > where aggregation occurs should change the semantics or > something else > > > > altogether? > > > > > > > > Rich > > > > > > > > > > > > *subbu@bea.com* > > > > > > > > 05/09/06 03:24 PM > > > > > > > > > > > > To > > > > wsrp@lists.oasis-open.org > > > > cc > > > > > > > > Subject > > > > [wsrp] [AJAX] Redirect behavior - clarification > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > When I raised the question of semantics of redirectURL, it was > > suggested > > > > that it can be treated as a regular full-page redirect. I would > > like to > > > > get some clarification on the behavior. > > > > > > > > When a browser submits an XHR and encounters a redirect, the > browser > > > > would follow the redirect and send the final response to the > script. > > > > Since the redirect target will most likely be outside the > > consumer, the > > > > consumer cannot include its own response when a redirect > happens. As a > > > > result, the (consumer supplied) client side script may not be > able to > > > > understand the response. > > > > > > > > I see three options: > > > > > > > > a. Disallow redirects. > > > > > > > > b. Let the consumer handle the redirect, and capture the response. > > This > > > > would give the consumer a chance to include its own response. > > > > > > > > c. Let the consumer send a redirect header to the browser, and > comment > > > > that consumer's script may just get the portlet's data/markup > in the > > > > response, and it should be ready to deal with it. > > > > > > > > I vote for (c). Any comments? > > > > > > > > Subbu > > > > > > > > > > --------------------------------------------------------------------- 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 > > > > > > > _______________________________________________________________________ > > > Notice: This email message, together with any attachments, may > contain > > > information of BEA Systems, Inc., its subsidiaries and > affiliated > > > entities, that may be confidential, proprietary, copyrighted > and/or > > > legally privileged, and is intended solely for the use of the > individual > > > or entity named in this message. If you are not the intended > recipient, > > > and have received this message in error, please immediately return > this > > > by email and then delete it. > > > > > > --------------------------------------------------------------------- > > > 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 > > > > _______________________________________________________________________ > > Notice: This email message, together with any attachments, may contain > > information of BEA Systems, Inc., its subsidiaries and affiliated > > entities, that may be confidential, proprietary, copyrighted and/or > > legally privileged, and is intended solely for the use of the individual > > or entity named in this message. If you are not the intended recipient, > > and have received this message in error, please immediately return this > > by email and then delete it. > > > > --------------------------------------------------------------------- > > 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 > > _______________________________________________________________________ > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual > or entity named in this message. If you are not the intended recipient, > and have received this message in error, please immediately return this > by email and then delete it. > > --------------------------------------------------------------------- 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 _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]