Perfect, thanks for digging Fil. I only asked the 'we' question because it seemed like the question was pasted, and I thought 'we' was referring to someone else entirely.
I have assigned the FileUploadOptions.params issue to myself here:CB-668 and will revisit the passing dynamic JSON issue. However this will require a re-write of many of the APIs. Back on track... On Tue, Jun 19, 2012 at 5:38 PM, Filip Maj <[email protected]> wrote: > "We" is us, collectively cordova - I didn¹t want to say "YOU" and point > fingers at who wrote the "failing" code. > > Totally could pass it as URL-encoded string, didn't even think of that. > Deciding on one way or another is all that matters to me. If we do change > it to url-encdoed string we would need all platforms to change the native > side. > > As for what do the params do, great question. A deep dive uncovered a lot > of shit... > > Android > --- > The "headers" key from the object is assumed to be an object. This > key:values inside the "headers" sub-object are then added as headers to > the HTTP request [1]. > All other non-"headers" keys from the params object are tacked on to the > HTTP request body like so: > > extraParams += "Content-Disposition: form-data; name=\"" + key.toString() > + "\";"; > extraParams += LINE_END + LINE_END; > extraParams += params.getString(key.toString()); > > > BlackBerry > --- > Does the same thing re content-disposition to the HTTP body, but does NOT > do the "headers" stuff [2]. > > iOS > --- > Magical "__cookie" property name gets tacked onto the HTTP request's > Cookie header [3]. > Other than that does the content-disposition stuff. > > -- SO -- > > I would say Windows Phone should JUST do the content-disposition > song-n-dance, and not worry about the headers/cookies. The reason for this > is the same reason we recently axed larger changes slated for Media, since > we are deprecating that API after 2.0. This is apparently going to happen > to FileTransfer as well, so IMO should not put too much effort into it. > > All of that said, the issue of passing dynamic JSON objects that we cannot > model ahead of time over the WP7 bridge still exists. Want to keep this > thread on track. > > [1] > https://github.com/apache/incubator-cordova-android/blob/master/framework/s > rc/org/apache/cordova/FileTransfer.java#L180-L190 > [2] > https://github.com/apache/incubator-cordova-blackberry-webworks/blob/master > /framework/ext/src/org/apache/cordova/http/FileUploader.java#L254 > [3] > https://github.com/apache/incubator-cordova-ios/blob/master/CordovaLib/Clas > ses/CDVFileTransfer.m#L92 > > On 6/19/12 4:49 PM, "Jesse" <[email protected]> wrote: > > >Where is this conversation coming from? it appears to be pasted from > >somewhere, who is 'we'? > > > >params is only allowed to be one level deep anyway so it should simply be > >a > >url-encoded string. > >How is the params value passed to the server on other platforms? > > > >The documentation simply states: > >*params:* A set of optional key/value pairs to be passed along in the HTTP > >request. (Object) > > > >Does it become headers? post data? consistently across other devices? > > > >I have reassigned the issue [3] to myself, and will address it shortly. > > > >[3] https://issues.apache.org/jira/browse/CB-668 > > > > > >On Tue, Jun 19, 2012 at 3:51 PM, Filip Maj <[email protected]> wrote: > > > >> ... Currently won't work. Basically the DataContractJsonSerializer .NET > >> object that we employ to parse JSON on the native side can't parse > >>nested > >> objects in JSON. The DataContract stuff is supposed to make it easy to > >> cast the various JSON values to .NET types. In the case of a nested > >>object > >> with dynamic keys, that you can't model ahead of time, we tried using a > >> Dictionary type on the native side. This won't work [1]. > >> > >> This came up when deserializing FileTransfer upload options because they > >> have a nested "params" object that house dynamic &key=value URL > >>parameters > >> to send with the HTTP request. Not sure if it happens in other spots. > >> > >> Anywho, one potential solution is to explicitly convert nested objects > >> such as these to a dumber structure. In the SO thread [1] they suggest > >> having an array of {key:"known1",value:"foo"} pairs replace the objects. > >> The native side could parse that. > >> > >> Another option is to use the JSON.net library [2]. MIT license. 300-ish > >>kb > >> .dll. > >> > >> The stock System.Json namespace that is available in .NET and has better > >> capabilities is not available on Windows Phone. > >> > >> Any other solutions/ideas/comments/thoughts? > >> > >> [1] > >> > >> > http://stackoverflow.com/questions/8064627/deserializing-json-object-with > >>-u > >> > >>nknown-fields< > http://stackoverflow.com/questions/8064627/deserializing-js > >>on-object-with-unknown-fields> > >> [2] http://json.codeplex.com/ > >> > >> > > > > > >-- > >@purplecabbage > >risingj.com > > -- @purplecabbage risingj.com
