I've had a go at updating this to match the Ext2.2 code.
The only bit I wasn't too sure about was the setting of headers.
E.g. the code...
Code:
hs['Content-Type']
This doesn't look right to me. I always thought that a hyphen was an invalid character for property names because it gets interpreted as a subtraction sign.
i.e.
Code:
hs.Content-Type
is the same as
Code:
(hs.Content)-Type
which is obvioulsy wrong. Maybe you can always get away with it if you only access the property via the square bracket notation?
Anyway, here is the code.
Max
@MaxT -- Javascript does not permit dashes in direct object-member references:
obj.Content-type
Must be done this way: obj['Content-type'] = something;
...which is why most JSON encoders force quotes around member names.
Built-in JSONP support (text, Object, JSON, XML ) -> to a native Ext response Object.
Request Queues
responseJSON support
Basic Auth
File system support.
other goodies, yada, yada...
Originally Posted by Animal
Can anyone provide a use case for synchronous requests?
@Animal -- Use cases:
Sequential (transactional) loading of a resource (JS, etc)
Realtime form validation server-side (intranets only recommended)
Originally Posted by MaxT
Ext-basex requires a Commercial licence. I don't see the point in buying one just to be able to do a synchronous request which can be coded in a few lines.
Max
@MaxT -- It's called dual-licensing: GPL 3.0/Commercial
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.
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.
Arrow
a few question about the syn ajax :
* it should be Ext.Ajax.request({ or Ext.lib.Ajax.request for the sample to call
Ext.Ajax.request({
url: 'some_page.php',
method: 'POST',
success: success,
failure: failure,
scope: this,
params: {foo: 'bar'},
async: false
});
* there are, extjs/ext-2.2/adapter/ext/ext-base.js and extjs/ext-2.2/ext-all.js,
you mentioned "This is ONLY for use with ext-base.js", does it means there will be a conflicting
at using ext-all.js ?
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.
Can anyone provide a use case for synchronous requests?
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.
Originally Posted by MaxT
Reply With Quote
