rec.raw()
instead of rec.toJSON()
? Using toJSON results in postBody ending up as a string rather than parameters/values.//* Uses "POST" if the _record_ is new, otherwise "PUT" for the method commit: function (rec, opts) { opts.method = rec.isNew? "POST": "PUT"; opts.url = this.buildUrl(rec, opts); //opts.postBody = rec.toJSON(); opts.postBody = rec.raw(); this.go(opts); },
It looks like you're new here. If you want to get involved, click one of these buttons!
Comments
postBody
property is in accordance with the same property inenyo.AjaxProperties
where it is a string to be supplied with a POST request.To your second comment yes and no. Yes because it has code for
enyo.Collection
and that it will have support for a to-one type relationship in the near future. No because technically there isn't any built-in support for the relationship so the fact thatenyo.Collection
is supported already is...inconsistent but shouldn't be a blocker.I will be working on relational soon.
1. In xhr.js, AjaxSource.commit function, I need to use rec.raw() instead of rec.toJSON() when POSTing; if I use the current version of rec.toJSON(), a string is submitted rather than parameter:value pairs in the postBody. 2. In Store.js, Store.addRecord function, I changed the throw statement to a console.log (or warn) and added a
rec=kinds[id];
line before it. This is to return the existing record (i.e., one with same primary key) so an existing record can be added to multiple collections. I did not want to use "ignoreDuplicates=true" because I actually don't want new instances created for same data. 3. Please see http://forums.enyojs.com/discussion/1923/suggestion-for-raw-function-in-model-js#latest re: Model.raw() function (same issue as my Nov 2013 post above).Just wondering what your thoughts on these are?
Any comments on above questions 2 and 3 above?
Re: #1, I understand that I need to change the contentType; however, looking at xhr.js and Ajax.js, it appears that the data in postBody is stringified before it gets to Ajax.request. Therefore Ajax.request will not look at Content-Type and pass it as a string to server?
Just wondering if I should be opening bug/feature requests for above or not.
Thanks.
Cage
In fact, i want to send params via GET, to add filters to my Collection fecth method.
I was about to suggest to add a toParams / toQueryString / stringify method into enyo, because i don't want to depends on jQuery, or anything else than Enyo.
So, I looked at enyo.Ajax.objectToQuery, but this method is completely wrong.
I tried: I got something un-interpretable: This is what I'm waiting for: This method MUST be corrected, to post Params from GET and POST.
Here are some implementation I found, but codes are always dependent of its core library (like isArray, etc...):
https://github.com/jquery/jquery/blob/master/src/serialize.js
http://yuilibrary.com/yui/docs/api/files/querystring_js_querystring-stringify.js.html#l25
Thanks !
1. The way the source works now is merely its "default" behavior. Its an optional mechanism where one could drop it in without change if they were engineering their backend to match. In many cases that is not possible and when working with remote sources we have to make modifications. To modify the behavior the most straightforward way I think would be to sub-kind enyo.AjaxSource and overload the _commit_ to do what you need. In this particular case the abstraction was designed so you could do this with relative ease. I'm thinking of any ways to make this better.
2. This will not be an issue after the work I'm doing now is released. For now, that may be the best thing to suit you in this case.
3. Without having seen your comment before now, I've addressed this in my current work. So moving forward it will be more versatile
But enyo's implemented version only formats correctly data if there are already atomic. But if we try to format an object, there is no recursion, so it prints "object Object", the best JS atomic interpretation of a non-atomic data. See the implemented versions of jQuery: they pass a prefix (the "path" of the parent which store the atomic propertie).
I'm sure it must be corrected.
@psarin: I think you're right, it also should fit AjaxProperties, formatting must match defined Content-Type. But if objectToQuery is not corrected, you would be able to only send simple data, but no complex objects.
EDIT: Here is a little Fiddle to illustrate: http://jsfiddle.net/RT3ne/
Traditionnal formatting can't serialize objects. Recursive formatting permits to have whole data in parameters. If we want to send Collections to server, we need to recursively format it, that's how HTML Forms naturally do.
I need it in my project, my Rails backend will record nested attributes passed in parameters. Plus, some complex objects may need it. Current version only supports atomic data. I will try to implement recursive objectToQuery for my project, I will then make a pull request if nobody does.