[ 
https://issues.apache.org/jira/browse/SLING-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vidar S. Ramdal updated SLING-1336:
-----------------------------------

    Attachment: SLING-1336-2.patch

The issue with the IOException constructor is fixed in this revised patch. 
At first, implementing Felix's other suggestions seemed easy, but proved more 
complicated:

>> Now, sling.servlets.post does not have a dependency to Engine. Do we want to 
>> introduce that? Or move RequestUtil to API?

> Right. Yes, moving RequestUtil to API might make sense, on the other hand, we 
> should probably not add more real classes to the API module. Rather I was 
> thinking of (yet another ?) commons module.

I suggest we create a separate task for this. Once we have RequestUtil in a 
separate bundle, that sling.servlet.post can depend on, we'll remove 
MediaRangeList and use RequestUtil.parseAcceptHeader.

>> This could probably be easily rewritten to use HtmlResponse's hashmap, and 
>> populating the JSONObject on send().

> I would prefer that even though it might seem a bit more expensive. The main 
> reason for me would be simplicity: You just have to overwrite a single method 
> - the rendering method - and otherwise have the exact same implementation. 
> For output JsonWriter could then be used instead of JSONObject. 

The problem is that HtmlResponse does not have a getProperties() method - only 
getProperty() methods to retrieve named properties. 
So that leaves me with two options: Either a) record keys of all properties 
that are changed in a set in JsonResponse, so we'll know which properties to 
get from HtmlResponse on send(). This kind of invalidates the simplicity 
argument :)
or b) implement a HtmlResponse.getProperties() method. Since HtmlResponse is in 
sling.api, this would mean that the dependency to API would have to be updated 
to 2.0.9-SNAPSHOT.

I'm inclined to leaving this as it is for the moment, so that this issue can be 
resolved with changes to no other bundles than sling.servlet.post. Which again 
means that we're not holding back a release of sling.servlet.post by 
introducing this feature.

WDYT?


> Let SlingPostServlet return JSON
> --------------------------------
>
>                 Key: SLING-1336
>                 URL: https://issues.apache.org/jira/browse/SLING-1336
>             Project: Sling
>          Issue Type: New Feature
>          Components: Servlets
>    Affects Versions: Servlets Post 2.0.4
>            Reporter: Vidar S. Ramdal
>            Assignee: Vidar S. Ramdal
>             Fix For: Servlets Post 2.0.6
>
>         Attachments: SLING-1336-2.patch, SLING-1336.patch
>
>
> From http://markmail.org/thread/ic2752rha4iy2s2c
> In many scenarios it would be nice to get JSON in response to a POST. You 
> could write your own post servlet to do that, but then you will not benefit 
> from the registered SlingPostOperations and SlingPostProcessors that are 
> executed by the default SlingPostServlet.
> In the case of SlingPostOperation, an implementing class is passed a 
> HtmlResponse object when run(). The HtmlResponse object is pretty agnostic to 
> response format though, the only HTML related work is in the send() method. 
> Thus, it should be possible ot replace/extend/abstract HtmlResponse with a 
> more generic response object. The send() functionality is then moved to 
> SlingPostServlet, which determines which format to return based on these 
> criteria (in order):
> 1. The Accept HTTP header - if set to "application/json" return JSON, 
> otherwise return HTML
> 2. Possibly also an :accept form field, with the same meaning as the HTTP 
> header, in case it is proven that setting the HTTP header does not work in 
> all browsers
> 3. The format of the posted data - if JSON is posted (see SLING-1172), return 
> JSON, otherwise return HTML

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to