On 4/9/10 3:58 PM, Felix Meschberger wrote:
> Hi,
>
> On 09.04.2010 21:32, Justin Edelson wrote:
>> Hmmm. You're right - I conflated extension with suffix.
>>
>> On 4/9/10 3:10 PM, Luca Masini wrote:
>>> Great, I never considered RequestDispatcherOptions and I think it's a
>>> good idea.
>>>
>>> But with replaceSuffix I go into an infinity cycle, because the servlet
>>> is choosen by the "jsonp" extension and not as a suffix:
>>>
>>> req.getRequestDispatcher(req.getResource().getPath(), new
>>> RequestDispatcherOptions("replaceSuffix=json")).include(req, resp);
>>>
>>>
>>> What is wrong with me ???
>>>
>>> Also, how can I associate a script like the one you showed to an
>>> extension ??
>> Create it at /apps/sling/servlet/default/jsonp.esp
>>
>> It doesn't look like there's a way to override the extension via
>> RequestDispatcherOptions. I guess what you can do is just hack the last
>> letter off the path (assuming you're using jsonp as the extension). But
>> now I have a bad taste...
>>
>> I can't think of a good reason why this is the case. It seems like there
>> should be a replaceExtension=json option.
>
> You could to
>
> req.getRequestDispatcher(req.getResource.getPath()+".jsonp")....
AFAICT, this won't work (and would need to be ".json" anyway) because
you lose all the selectors. i.e.
/foo/bar/res.tidy.jsonp (resource path = /foo/bar)
should be a padded version of
/foo/bar/res.tidy.json
but if you just replace tack on the extension to the resource path, it
would be /foo/bar/res.json.
Obviously you could recreate the selectors if you needed to, but this is
why it seems to me that replaceExtension would be useful. I see a typo
in what I wrote... it should be:
<%= request.getParameter("jsonp") %>(<% sling.include(resource,
"replaceExtension=json") %>)
>
> to overwrite the request extension.
>
> But: we didn't do this by intent: Since we assume an expected content
> type from the request extension changing the extension for request
> processing might interfere with these expectations.
Maybe I'm missing something, but how could it interfere?
If I have html.esp, what is the harm in being able to include the result
of txt.esp or json.esp? The response content type is still text/html. I
agree that this probably wouldn't be very common, but I don't see the harm.
>
> Now, what would hinder use to add support for JSONP in our JSON servlets
> ? We could, for example add JSONP servlets to the Default GET Servlet
> bundle which internally use the existing servlets but add the padding.
Time ;)
Justin
>
> Regards
> Felix
>
>>
>> Justin
>>
>>
>>
>>>
>>> Thank you for your help.
>>>
>>> On Fri, Apr 9, 2010 at 8:05 PM, Justin Edelson <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> These two servlets are used in different contexts, so it makes sense
>>> that you'd use different patterns for each of them. Your approach to the
>>> JsonQueryServlet looks fine to me. For the renderer servlet, I would be
>>> more inclined to create a script registered with the "jsonp" extension
>>> which is basically this:
>>>
>>> <%= request.getParameter("jsonp") %>(<%
>>> sling.include(resource.getPath(), "replaceSuffix=json") %>)
>>>
>>> Justin
>>>
>>> On 4/7/10 4:52 PM, Luca Masini wrote:
>>> > Yes, that can be great, but I don't want to change Sling sources, only
>>> > reuse them, that's why I asked about best practices.
>>> >
>>> > On Wed, Apr 7, 2010 at 9:58 PM, Justin Edelson
>>> <[email protected] <mailto:[email protected]>
>>> > <mailto:[email protected] <mailto:[email protected]>>>
>>> wrote:
>>> >
>>> > We should probably just support jsonp natively in these servlets.
>>> >
>>> >
>>> > On 4/7/10 2:05 PM, Luca Masini wrote:
>>> > > Hi guys, I need an advice from Sling experts.
>>> > >
>>> > > I need a JSONP renderer for Sling, initially I thought I had to
>>> > develop only
>>> > > one, but after I discovered that in effect Sling has two
>>> renderer
>>> > for JSON,
>>> > > one for plain resources and one for query.
>>> > >
>>> > > These two renderer are in private packages in a Sling
>>> Bundle, and
>>> > because
>>> > > JSONP and JSON are quite equals and I wanted to reuse as much as
>>> > possible, I
>>> > > started thinking about strategies to call them.
>>> > >
>>> > > The JsonQueryServlet is deployed as an OSGi Component, so I was
>>> > able to
>>> > > inject it using Felix SCR Annotation (querying for his
>>> > properties), and then
>>> > > I called his service() method inside my doGet:
>>> > >
>>> > > servlet.service(req, resp);
>>> > >
>>> > > For the JsonRendererServlet instead I used another strategy.
>>> > >
>>> > > I extracted the RequestPathInfo from the SlingHttpServletRequest
>>> > and the I
>>> > > included it using RequestDispatcher:
>>> > >
>>> > > String jsonPath = calculateIt(req);
>>> > >
>>> > > req.getRequestDispatcher(jsonPath).include(req, resp);
>>> > >
>>> > > Now both of these two are working, but I have a bad taste.
>>> > >
>>> > > Which of this is the best approach ?? The first ?? The second ??
>>> > None of
>>> > > them ???
>>> > >
>>> > >
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > ****************************************
>>> > http://www.lucamasini.net
>>> > http://twitter.com/lmasini
>>> > http://www.linkedin.com/pub/luca-masini/7/10/2b9
>>> > ****************************************
>>>
>>>
>>>
>>>
>>> --
>>> ****************************************
>>> http://www.lucamasini.net
>>> http://twitter.com/lmasini
>>> http://www.linkedin.com/pub/luca-masini/7/10/2b9
>>> ****************************************
>>
>>
