headers

I still think hs['Content-Type'] is a weak implementation because the string "Content-Type" is case insensitive with HTTP. This forces you to use ['Content-Type'] and not any other valid string for the name component of the header field.

Whilst ext-basex has a dual licence, in my case I can't use GPL 3 for my code. As I have no use at the present time for the other features of the extension it is not worth buying it just to be able to add a synchronous Ajax request. No doubt there are other Ext users, with a commercial Ext licence, in a similar situation and the above patch may help.

Use case for asynchronous http request

A possible use case: in TreePanel.beforeNodeDrop(), I want to perform server-side rather than client-side validation of the drop so that the logic about valid drop locations doesn't have to reside in the client. beforeNodeDrop() must return false to stop the drop, but it returns without receiving a response from the server. The server response can only be captured in the callback, but from there you can't control what beforeNodeDrop() returns. Is there a way to do this other than using a synchronous call?

A possible use case: in TreePanel.beforeNodeDrop(), I want to perform server-side rather than client-side validation of the drop so that the logic about valid drop locations doesn't have to reside in the client. beforeNodeDrop() must return false to stop the drop, but it returns without receiving a response from the server. The server response can only be captured in the callback, but from there you can't control what beforeNodeDrop() returns. Is there a way to do this other than using a synchronous call?

True, you cannot do async call in a beforeNodeDrop, but you could do it ( I do it that way ) easily with just adding additional attribute to the node data, that's returned initially from your server, and then use it like node.attributes.can_drop or so, with simple calculations inside JavaScript. This will save you a LOT of calls to your server, as you move over your nodes, there will be a lot of them.

True, you cannot do async call in a beforeNodeDrop, but you could do it ( I do it that way ) easily with just adding additional attribute to the node data, that's returned initially from your server, and then use it like node.attributes.can_drop or so, with simple calculations inside JavaScript. This will save you a LOT of calls to your server, as you move over your nodes, there will be a lot of them.

In this case, the validity of the drop depends on properties of both the source and target, so it's not as simple as adding attributes to the nodes. Note that beforeNodeDrop is only called right before an actual drop, not as the node is dragged around, so the concern over lots of server calls is not valid.

A use case should not be necessary. If the underlying functionality that ExtJS is abstracting away allow synchronous requests, then so should ExtJS. To not do so would be like an ORM framework that does not allow you to issue raw SQL queries. Certainly 98+% of the time you just want to let the framework do the work for you, but when the framework disallows you from doing work you could do, but for the framework, then the framework has just become less valuable, and possibly a hindrance.