>> 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.
On Wed, Jan 27, 2010 at 12:08 PM, Alexander Klimetschek <[email protected]> wrote: > 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 ;-)) Definately needs to be tested, yes :) >>> 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. > [...] > The returned HTML is parsed for you by the browser > and the dom can easily be traversed to extract the various fields. When rendering the result in an IFRAME, yes, but not (AFAIK) when the HTML is returned in an XmlHttpRequest response body. (Side note: Could we modify HtmlResponse.html ever so slightly, so that it as least is XHTML? That would make processing it from a XmlHttpRequest response body much easier.) HtmlResponse is in the exported in o.a.s.api.servlets, so we probably can't mess around with it a lot, for backward compatibility. The HtmlResponse.send() method is public, but I guess it is intended for use only from SlingPostServlet? I suggest we deprecate HtmlResponse, and create a subclass of it called, say, PostResponse. "Subclassing" to create a more generic class sounds weird, but I'm not sure how we otherwise could preserve compatibility. The HtmlResponse.send() is deprecated, and its functionality moved to SlingPostServlet as sendHtml(). We also introduce SlingPostServlet.sendJson(). Finally, we implement the logic for choosing either sendHtml() or sendJson(), based on: 1. The format of the posted data - if JSON is posted (SLING-1172), return JSON, otherwise return HTML 2. The Accept HTTP header - if set to "application/json" return JSON, otherwise return HTML 3. Possibly also an :accept form field, with the same value as the HTTP header, in case it is proven that setting the HTTP header does not work in some browsers Does this make any sense at all? >>> 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. Sounds good. > 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 Yes, processing JSON posts is a totally different issue, in my opinion. -- Vidar S. Ramdal <[email protected]> - http://www.idium.no Sommerrogata 13-15, N-0255 Oslo, Norway + 47 22 00 84 00 / +47 21 531941, ext 2070
