Hi,
Am Freitag, den 23.05.2008, 12:05 -0400 schrieb Lars Trieloff:
> Hi,
>
> I am planning to add support for additional content types to the
> SlingPostServlet that would allow processing Web Forms 2.0, JSON
> (allowing an effective-round-tripping from Sling.js), XML (in JCR
> document notation), ATOM (in terms of the Atom publishing protocol).
As I said in another mail, we might want to separate support for
multiple transfer formats for operation feeding from the ":import"
operation stipulated by the roundtripping of JSON (and XML) exports --
maybe not. Let's see below
> To do this I would like to propose a small API change: extracting a
> ResponseBuilder interface from our current HtmlResponse and renaming
> HtmlResponse subsequently to HtmlResponseBuilder. This would allow us
> to create a doPost method that would start like this (I think we
> should OSGi-ify this later to make content type handling pluggable)
>
> protected void doPost(SlingHttpServletRequest request,
> SlingHttpServletResponse response) throws IOException {
>
> log.info("content-type: " + request.getContentType());
> String responseType;
> //try to determine the request content type and set the response
> accordingly. Ordinary
> //web forms (multipart/form-data or application/x-www-form-
> urlencoded) are getting HTML
> //response
> if (request.getContentType().equals("application/x-www-form
> +xml")) {
> responseType = "application/x-www-form+xml";
>
> //TODO: handle Web Forms 2.0 POST
> } else if (request.getContentType().equals("application/json")||
> request.getContentType().equals("text/x-json")) {
> responseType = "application/json";
>
> //TODO: handle JSON POST
> } else if (request.getContentType().equals("text/xml")) {
> responseType = "text/xml";
>
> //TODO: handle XML POST
> } else if (request.getContentType().equals("application/atom
> +xml")) {
> responseType = "application/atom+xml";
>
> //TODO: handle Atom POST
> } else {
> responseType = "text/html";
> }
>
> //check for user-specified override of response type
> if (request.getHeader("Accept")!
> =null&&request.getHeader("Accept").length()!=0) {
>
> responseType = request.getHeader("Accept");
> }
>
> ResponseBuilder responseBuilder;
> if (responseType.equals("application/json")) {
> responseBuilder = new JsonResponseBuilder();
> } else if (responseType.equals("application/x-www-form+xml")) {
> responseBuilder = new WebForms20ResponseBuilder();
> } else if (responseType.equals("text/xml")) {
> responseBuilder = new XmlResponseBuilder();
> } else if (responseType.equals("application/atom+xml")) {
> responseBuilder = new AppResponseBuilder();
> } else {
> responseBuilder = new HtmlResponseBuilder();
> }
>
> the general idea is not to break the current API, so that HtmlResponse
> stays the default, but that users sending a JSON request will get a
> JSON response, unless they explicitly request a different responseType
> using the Accept header.
>
> If this sounds good to you, I would go on by writing the Web Forms 2.0
> part first and submitting a patch (on Youtube) including the proposed
> API changes.
I think, this sounds interesting -- and I would make it configurable
right from the start. What you are proposing is, that we properly
separate the request data parsing and response data generation from the
actual processing.
<thinking_loudly>
We would have an input processor selected by the request content type
and defaulting to plain old request parameter support as available
through SlingHttpServletRequest.getParameter (e.a.). The input processor
would also provide the ResponseBuilder.
Processing would be along these lines:
InputProcessor ip = getInputProcessor(request);
if (ip == null) {
ip = httpInputProcessor;
}
String operation = ip.getOperation();
Operation op = getOperation(operation);
op.execute(ip.getRequestParameters(), ip.getResponseBuilder());
ip.getResponseBuilder.send();
That is the InputProcessor would provide the input data as abstract
parameters for the operations to uniformly access them.
The operations would the operate solely on the parameters and write back
response data to the ResponseBuilder.
</thinking_loudly>
Now, looking at this mechanism, the ":import" operation being built by
Paul Noden could in fact just be a InputProcessor for JSON (or whatever
format). In this respect :import is just a content creation/modification
operation [which in fact it is to a certain extent].
Regards
Felix
>
> regards,
>
> Lars
