Re: [wsrp] [AJAX] Redirect behavior - clarification

[Rich Thompson <richt2@us.ibm.com>]

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