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")....
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.
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.
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
>> ****************************************
>
>
