[ext-basex/$JIT 4.0 adapter extensions] Ajax enhancements and more.

[hendricd]

mmh, what if treepanel or gridpanel are calling ajax.request then? options.queue will be false they are going not to be queued.. (or maybe i do not correly understand the if statement here..)

To clarify:

if((options.queue || (options.queue = Ext.lib.Ajax.queueAll))  && !options.queued){ 

This asserts request.options.queue first (from a higher level component like TreeLoader), else (||) assert options.queue to lib.Ajax default (false, true, or Qconfig{}).

Of course you could still provide a queue configs on either TreeLoader or the Grid's Proxy as well.

[wm003]

Ah, i understand now. Thanks. Are you going to implement this into the final 3.0 of basex?

[hendricd]

Ah, i understand now. Thanks. Are you going to implement this into the final 3.0 of basex?

You'll see it in beta2.

[coderobo]

I setup a redirect handler using -

  

function redirectHandler(conn, response, options ) {
  debugger;
}
...
Ext.lib.Ajax.on('status:302', redirectHandler, this);

However when a JSON store load causes the server to return a 302, the redirectHandler never gets a chance to intercept the call. The browser (FF2) seems to preempt it by following the redirect, fetching the redirected page (login page) and stuffing the final 200 OK login response page to the JSON store loader.

I can see the above behavior using FF LiveHeaders add-on as well as using the std Ext Ajax event handler -

Ext.Ajax.on(
    'requestcomplete' , redirectHandler 
   );

The requestcomplete handler only gets to fire after the browser has followed the 302 and got to the final page with a status of 200.

So the question that comes to the surface - Is this a bug in the ext-basex (I have tried 2.3 and 3.0 beta1) or the basex library can't trap 302 by virtue of any design limitations ?

The JSON store uses an HttpProxy w/o instantiating a new Connection object to allow it to get to the Singleton Ajax object:

function mkHttpProxy(tableid) {
 return new Ext.data.HttpProxy({
      url: 'itables/'+tableid+'-json.jsp'
 });

var store = new Ext.data.Store({
    proxy: mkHttpProxy(tableid),
    ....

Regards

[hendricd]

Yes, 302 will generally be handled by the browser for you, so you'll have rather limited success with that.

If the session has indeed expired, your server should respond with 40x status, and then you can handle recovery/login screen client-side in a controlled fashion.

[coderobo]

Yes, 302 will generally be handled by the browser for you, so you'll have rather limited success with that.

If the session has indeed expired, your server should respond with 40x status, and then you can handle recovery/login screen client-side in a controlled fashion.

Thanks Hendicd - The 40X are trapped so they are fine. Its the initial login that is triggered via a 302 that is the root of the problem. I am using a J2EE app server that uses the standard form-auth mechanism via a 302 redirect to login page. I don't have control over it. I suppose some messy server side programming could be used to trap the redirects and turn them into a 401 or an appropriate JSON response.

The more I use ext and Ext ux I realize it represents a paradigm shift from the Web 1.0 world. Perhaps these pitfalls should be mentioned in a FAQ.

Thanks

[hendricd]

Wonder if you could set a header in the login POST and have the serverside avoid the redirect if it's present.

[coderobo]

Wonder if you could set a header in the login POST and have the serverside avoid the redirect if it's present.

Yeah I am writing a Java Servlet filter that will trap the redirect and convert it into a 401 if it sees the XHR header in a POST.

[hendricd]

See, this for latest changes.

[Eric24]

Doug,

What should I know about the simultaneous requests limit? Your defaults are 2 for IE and 4 for FF. What's behind that? Are there any guidelines or hard limits regarding this?

Thanks!