On Wed, Jan 27, 2010 at 11:21, Vidar Ramdal <[email protected]> wrote: > Ah yes, but I think we've been down that road before. What if I > actually want to post to a node called /foobar.json > (node.getName().equals("foobar.json"))?
Ok, that might be an issue then. > Maybe we could use the Accept header from the request [1] instead - if > the client wants JSON (by specifying application/json in Accept), let > it have JSON - if not, return HTML. Yes. Is it possible to set the Accept header for XHRs in all browsers? (I guess yes, but these kinds of things really have to be tested ;-)) >> But some background on the html response: The reason why it was chosen >> is because it is the only response that works, ie. that is parseable >> by a javascript browser client, when you post a form to the >> SlingPostServlet via a hidden iframe (to post forms in an ajax style >> _and_ support file uploads). With an iframe, the response cannot be >> json, but only html. The structured html of the sling html response >> allows you to parse out the message, status, etc. > > True, but since the HtmlResponse template is not XML, it's not easily > dealt with in e.g. dojo.xhrPost() response handlers. Yes, and other responses should be possible for pure XHR and/or non-browser HTTP clients. I was simply talking about the full scope with in-browser forms that include file uploads - these have to be multi-part form encoded, and you can't do this with XHR, only with iframes. Therefor this was chosen as the default mechanism for the sling post servlet. The returned HTML is parsed for you by the browser and the dom can easily be traversed to extract the various fields. But yes, its a not so pretty workaround. Support for simpler request/response body formats is a good thing. >> So in the end, the usable combinations for the SlingPostServlet will >> probably be: >> form post => html response >> json post => json response > > But if we look for the Accept header (and perhaps also an equivalent > request parameter, like :accept), shouldn't we be able to determine > response type regardless of form post type? Right, I wasn't really suggesting to bake in these fixed combinations, I was just guessing what will be typical in the end. Parsing XML/HTML in xhr response for example is unnecessary because JSON is much simpler. So maybe we use the type of the request body as the default, then look at the Accept header. I think we should only introduce an :accept field, if the Accept header doesn't work for all cases. Also, if we want to support JSON posts, we need some thinking about it: it allows for more structure than the form post with a flat list of fields and one might want to make it look like the json returned from the json get servlet to allow for round trips. The sling json content loader mechanism (used upon bundle installation) might be used for that. Although that is a somewhat separate discussion for https://issues.apache.org/jira/browse/SLING-1172 Regards, Alex -- Alexander Klimetschek [email protected]
