Hi,
On 09.04.2010 22:45, Justin Edelson wrote:
> 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.
Sure, this was just a no-brainer example ;-)
>
> /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 ;)
Hehe.
Well, for the JsonQueryServlet it is probably even simpler (and amounts
to a four-some liner:
if (request.getParameter("padding") != null) {
response.write("padding(");
}
... do the rest
if (request.getParameter("padding") != null) {
response.write(");");
}
For the JsonRenderer, we might consider using a suffix or also a request
parameter.
Regards
Felix
>
> 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
>>>> ****************************************
>>>
>>>
>
>
