You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Christophe Lombart <ch...@gmail.com> on 2008/06/18 13:42:51 UTC
Json Rendering
Hi all,
I would like to modify the Json rendering. I want to add the node path &
name. What is the best way to extend the JsonServlet for this kind of
requirements ? I would like to do it for any kind of resource types & Jcr
Node types. That's why I would like to avoid to add a new scripts for each
types. I thought to build my own json servlet bur I'm just wondering if
there is not another way to do that.
Thanks,
Christophe
Re: Json Rendering
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Jun 18, 2008 at 5:13 PM, Craig L. Ching <cc...@mqsoftware.com> wrote:
> ...how do I map the selector to my new servlet? In other
> words, is there a way to map to a servlet based on selector? ...
Yes, http://incubator.apache.org/sling/site/servlet-resolution.html
has the docs (didn't check if they're fully up to date), and the
JsonQueryServlet [1] is a good example:
* @scr.property name="sling.servlet.resourceTypes"
* value="sling/servlet/default"
* @scr.property name="sling.servlet.extensions" value="json"
* @scr.property name="sling.servlet.selectors" value="query"
In this case the servlets handles .query.json requests.
So you just have to invent a selector, extend the JsonRendererServlet,
register it as above and that should work.
-Bertrand
[1] http://svn.apache.org/repos/asf/incubator/sling/trunk/servlets/get/src/main/java/org/apache/sling/servlets/get/JsonQueryServlet.java
RE: Json Rendering
Posted by "Craig L. Ching" <cc...@mqsoftware.com>.
> selector? I may be showing my sling noobness here ;-) Feel
> free to point me to the documentation if it's documented, I
> have a feeling I've read about this already and I'm just not
> recalling ...
>
Ok, think I found the doc [1], let me see if I can put something
together based on this then. Thanks!
[1] -- http://incubator.apache.org/sling/site/servlet-resolution.html
>
> Cheers,
> Craig
>
Cheers,
Craig
RE: Json Rendering
Posted by "Craig L. Ching" <cc...@mqsoftware.com>.
Hi Bertrand,
> -----Original Message-----
> From: bdelacretaz@gmail.com [mailto:bdelacretaz@gmail.com] On
> Behalf Of Bertrand Delacretaz
> Sent: Wednesday, June 18, 2008 10:08 AM
> To: sling-dev@incubator.apache.org
> Subject: Re: Json Rendering
>
> Hi Craig,
>
> On Wed, Jun 18, 2008 at 4:18 PM, Craig L. Ching
> <cc...@mqsoftware.com> wrote:
> > ... have a patch here
> > (https://issues.apache.org/jira/browse/SLING-518) that I'm
> waiting for
> > someone to give guidance on....
>
> I had a quick look, and I think creating a custom JSON
> rendering servlet, by inheriting from the
> JsonRendererServlet, and wirting that to the json extension
> and a specific selector might be better that the proposed
> patch. Unless you guys can come up with a simple generalized
> way of "flavoring" the JSON output.
>
Ok, you didn't like my hard-coded meta selector in the existing servlet
then? ;-) I kind of figured that a whole new servlet would have been
overkill for this, but I'm happy to do what you guys think is best.
Question then, how do I map the selector to my new servlet? In other
words, is there a way to map to a servlet based on selector? I may be
showing my sling noobness here ;-) Feel free to point me to the
documentation if it's documented, I have a feeling I've read about this
already and I'm just not recalling ...
Thanks for the input!
> -Bertrand
>
Cheers,
Craig
Re: Json Rendering
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Craig,
On Wed, Jun 18, 2008 at 4:18 PM, Craig L. Ching <cc...@mqsoftware.com> wrote:
> ... have a patch here
> (https://issues.apache.org/jira/browse/SLING-518) that I'm waiting for
> someone to give guidance on....
I had a quick look, and I think creating a custom JSON rendering
servlet, by inheriting from the JsonRendererServlet, and wirting that
to the json extension and a specific selector might be better that the
proposed patch. Unless you guys can come up with a simple generalized
way of "flavoring" the JSON output.
-Bertrand
Re: Json Rendering
Posted by Christophe Lombart <ch...@gmail.com>.
ok I will look at this.
Thanks
Christophe
On Wed, Jun 18, 2008 at 4:18 PM, Craig L. Ching <cc...@mqsoftware.com>
wrote:
> Hi Christophe,
>
> I'm not sure if this interests you or not, but I have a similar need
> with respect to the JCR explorer. I have a patch here
> (https://issues.apache.org/jira/browse/SLING-518) that I'm waiting for
> someone to give guidance on. I'd be happy to hear what you come up with
> and maybe we can find a good, extensible solution together. If nothing
> else, maybe it gives you an idea of how to proceed.
>
> Cheers,
> Craig
>
> > -----Original Message-----
> > From: Christophe Lombart [mailto:christophe.lombart@gmail.com]
> > Sent: Wednesday, June 18, 2008 6:43 AM
> > To: sling-dev@incubator.apache.org
> > Subject: Json Rendering
> >
> > Hi all,
> >
> > I would like to modify the Json rendering. I want to add the
> > node path & name. What is the best way to extend the
> > JsonServlet for this kind of requirements ? I would like to
> > do it for any kind of resource types & Jcr Node types. That's
> > why I would like to avoid to add a new scripts for each
> > types. I thought to build my own json servlet bur I'm just
> > wondering if there is not another way to do that.
> >
> >
> > Thanks,
> > Christophe
> >
> >
>
RE: Json Rendering
Posted by "Craig L. Ching" <cc...@mqsoftware.com>.
Hi Christophe,
I'm not sure if this interests you or not, but I have a similar need
with respect to the JCR explorer. I have a patch here
(https://issues.apache.org/jira/browse/SLING-518) that I'm waiting for
someone to give guidance on. I'd be happy to hear what you come up with
and maybe we can find a good, extensible solution together. If nothing
else, maybe it gives you an idea of how to proceed.
Cheers,
Craig
> -----Original Message-----
> From: Christophe Lombart [mailto:christophe.lombart@gmail.com]
> Sent: Wednesday, June 18, 2008 6:43 AM
> To: sling-dev@incubator.apache.org
> Subject: Json Rendering
>
> Hi all,
>
> I would like to modify the Json rendering. I want to add the
> node path & name. What is the best way to extend the
> JsonServlet for this kind of requirements ? I would like to
> do it for any kind of resource types & Jcr Node types. That's
> why I would like to avoid to add a new scripts for each
> types. I thought to build my own json servlet bur I'm just
> wondering if there is not another way to do that.
>
>
> Thanks,
> Christophe
>
>
Re: Json Rendering
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Jun 18, 2008 at 3:58 PM, Felix Meschberger <fm...@gmail.com> wrote:
> ...The simple way to provide a default servlet just for JSON
> is to create a script such as /apps/sling/servlet/default/json.esp...
Good one - I forgot about this option, but you're right that it's the
simplest way to experiment.
I have added the explanation to the FAQ at
http://cwiki.apache.org/SLING/faq.html .
-Bertrand
Re: Json Rendering
Posted by Christophe Lombart <ch...@gmail.com>.
On Wed, Jun 18, 2008 at 3:58 PM, Felix Meschberger <fm...@gmail.com>
wrote:
> Hi,
>
> Am Mittwoch, den 18.06.2008, 15:52 +0200 schrieb Christophe Lombart:
> > In my use case, only one thing is missing in the current implementation.
> > Maybe I'm wrong but I think it is not possible to apply the same script
> for
> > all kind of Sling resource types and/or Jcr Node types.
> >
> > For example :
> > If the case of a GET with a Json extension (with or without selectors) is
> > required, I would like to resolve the same esp script. Is it not a
> simple
> > solution ? WDYT?
>
> Yes, for sure. The simple way to provide a default servlet just for JSON
> is to create a script such as /apps/sling/servlet/default/json.esp
ok thanks :-) I didn't know that
or
> register a servlet with the json extension as Betrand said.
>
> This allows you to completely replace the existing default JSON renderer
> for all resource types which do not have their on json servlet or
> script.
>
> Hope this helps.
>
> Regads
> Felix
>
>
> >
> > On Wed, Jun 18, 2008 at 3:41 PM, Carsten Ziegeler <cz...@apache.org>
> > wrote:
> >
> > > Alexander Klimetschek wrote:
> > >
> > >> On Wed, Jun 18, 2008 at 2:04 PM, Bertrand Delacretaz
> > >> <bd...@apache.org> wrote:
> > >>
> > >>> Something like providing a new JsonWriter component at runtime ?
> > >>>>
> > >>> Yes, that would work. We could also have a JsonWriterFactory that's
> an
> > >>> OSGi service, but that feels like overkill right now.
> > >>>
> > >>
> > >> Yes, I have the same feeling. I think it is a general issue: as the
> > >> default servlets are a core feature in Sling (ie. simple updating of
> > >> JCR content), but very often you want to customize the behaviour for
> > >> certain properties or nodes, this seems like a general pattern, that
> > >> yet needs to be solved. Having a different plugin architecture in each
> > >> default servlet (providing custom writers, request objects etc.) feels
> > >> like the wrong solution. Especially if you consider the elegant way of
> > >> script/servlet resolution in Sling by using resource-types with
> > >> inheritance etc.
> > >>
> > >> IMHO this is the same (development) problem that Ruby on Rails solved
> > >> very well: using scaffolding to provide a working out-of-the-box
> > >> experience but then also allowing you to refine the default behaviour
> > >> step-by-step. The way it's done in Ruby is a combination of source
> > >> generating scripts, code generating logic in the classes itself (easy
> > >> with a dynamic language) and also using Ruby's missing-method (that is
> > >> called when a method is called that is not defined on the object).
> > >>
> > >> I have no clear solution in my head, but I think it's a place where
> > >> Sling could improve. WDYT?
> > >>
> > >> Not sure :) Can we first collect the possible use cases? Is one use
> case
> > > to replace the json renderer completely? Or do you want to use a
> different
> > > json renderer depending on the path or the resource type?
> > >
> > > Carsten
> > >
> > > --
> > > Carsten Ziegeler
> > > cziegeler@apache.org
> > >
>
>
Re: Json Rendering
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Mittwoch, den 18.06.2008, 15:52 +0200 schrieb Christophe Lombart:
> In my use case, only one thing is missing in the current implementation.
> Maybe I'm wrong but I think it is not possible to apply the same script for
> all kind of Sling resource types and/or Jcr Node types.
>
> For example :
> If the case of a GET with a Json extension (with or without selectors) is
> required, I would like to resolve the same esp script. Is it not a simple
> solution ? WDYT?
Yes, for sure. The simple way to provide a default servlet just for JSON
is to create a script such as /apps/sling/servlet/default/json.esp or
register a servlet with the json extension as Betrand said.
This allows you to completely replace the existing default JSON renderer
for all resource types which do not have their on json servlet or
script.
Hope this helps.
Regads
Felix
>
> On Wed, Jun 18, 2008 at 3:41 PM, Carsten Ziegeler <cz...@apache.org>
> wrote:
>
> > Alexander Klimetschek wrote:
> >
> >> On Wed, Jun 18, 2008 at 2:04 PM, Bertrand Delacretaz
> >> <bd...@apache.org> wrote:
> >>
> >>> Something like providing a new JsonWriter component at runtime ?
> >>>>
> >>> Yes, that would work. We could also have a JsonWriterFactory that's an
> >>> OSGi service, but that feels like overkill right now.
> >>>
> >>
> >> Yes, I have the same feeling. I think it is a general issue: as the
> >> default servlets are a core feature in Sling (ie. simple updating of
> >> JCR content), but very often you want to customize the behaviour for
> >> certain properties or nodes, this seems like a general pattern, that
> >> yet needs to be solved. Having a different plugin architecture in each
> >> default servlet (providing custom writers, request objects etc.) feels
> >> like the wrong solution. Especially if you consider the elegant way of
> >> script/servlet resolution in Sling by using resource-types with
> >> inheritance etc.
> >>
> >> IMHO this is the same (development) problem that Ruby on Rails solved
> >> very well: using scaffolding to provide a working out-of-the-box
> >> experience but then also allowing you to refine the default behaviour
> >> step-by-step. The way it's done in Ruby is a combination of source
> >> generating scripts, code generating logic in the classes itself (easy
> >> with a dynamic language) and also using Ruby's missing-method (that is
> >> called when a method is called that is not defined on the object).
> >>
> >> I have no clear solution in my head, but I think it's a place where
> >> Sling could improve. WDYT?
> >>
> >> Not sure :) Can we first collect the possible use cases? Is one use case
> > to replace the json renderer completely? Or do you want to use a different
> > json renderer depending on the path or the resource type?
> >
> > Carsten
> >
> > --
> > Carsten Ziegeler
> > cziegeler@apache.org
> >
Re: Json Rendering
Posted by Christophe Lombart <ch...@gmail.com>.
In my use case, only one thing is missing in the current implementation.
Maybe I'm wrong but I think it is not possible to apply the same script for
all kind of Sling resource types and/or Jcr Node types.
For example :
If the case of a GET with a Json extension (with or without selectors) is
required, I would like to resolve the same esp script. Is it not a simple
solution ? WDYT?
On Wed, Jun 18, 2008 at 3:41 PM, Carsten Ziegeler <cz...@apache.org>
wrote:
> Alexander Klimetschek wrote:
>
>> On Wed, Jun 18, 2008 at 2:04 PM, Bertrand Delacretaz
>> <bd...@apache.org> wrote:
>>
>>> Something like providing a new JsonWriter component at runtime ?
>>>>
>>> Yes, that would work. We could also have a JsonWriterFactory that's an
>>> OSGi service, but that feels like overkill right now.
>>>
>>
>> Yes, I have the same feeling. I think it is a general issue: as the
>> default servlets are a core feature in Sling (ie. simple updating of
>> JCR content), but very often you want to customize the behaviour for
>> certain properties or nodes, this seems like a general pattern, that
>> yet needs to be solved. Having a different plugin architecture in each
>> default servlet (providing custom writers, request objects etc.) feels
>> like the wrong solution. Especially if you consider the elegant way of
>> script/servlet resolution in Sling by using resource-types with
>> inheritance etc.
>>
>> IMHO this is the same (development) problem that Ruby on Rails solved
>> very well: using scaffolding to provide a working out-of-the-box
>> experience but then also allowing you to refine the default behaviour
>> step-by-step. The way it's done in Ruby is a combination of source
>> generating scripts, code generating logic in the classes itself (easy
>> with a dynamic language) and also using Ruby's missing-method (that is
>> called when a method is called that is not defined on the object).
>>
>> I have no clear solution in my head, but I think it's a place where
>> Sling could improve. WDYT?
>>
>> Not sure :) Can we first collect the possible use cases? Is one use case
> to replace the json renderer completely? Or do you want to use a different
> json renderer depending on the path or the resource type?
>
> Carsten
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
Re: Json Rendering
Posted by Alexander Klimetschek <ak...@day.com>.
On Wed, Jun 18, 2008 at 3:41 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> Not sure :) Can we first collect the possible use cases?
Of course. I just wanted to start a discussion.
> Is one use case to
> replace the json renderer completely? Or do you want to use a different json
> renderer depending on the path or the resource type?
I am talking about all default servlets, including the POST servlet.
Here you might want to handle certain properties differently. Maybe
filters are the way to go, but extensible default servlets are needed
as well, so that you basically only have to write your custom code (in
servlets and scripts) but don't have to copy-and-paste existing
default logic.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Json Rendering
Posted by Carsten Ziegeler <cz...@apache.org>.
Alexander Klimetschek wrote:
> On Wed, Jun 18, 2008 at 2:04 PM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>>> Something like providing a new JsonWriter component at runtime ?
>> Yes, that would work. We could also have a JsonWriterFactory that's an
>> OSGi service, but that feels like overkill right now.
>
> Yes, I have the same feeling. I think it is a general issue: as the
> default servlets are a core feature in Sling (ie. simple updating of
> JCR content), but very often you want to customize the behaviour for
> certain properties or nodes, this seems like a general pattern, that
> yet needs to be solved. Having a different plugin architecture in each
> default servlet (providing custom writers, request objects etc.) feels
> like the wrong solution. Especially if you consider the elegant way of
> script/servlet resolution in Sling by using resource-types with
> inheritance etc.
>
> IMHO this is the same (development) problem that Ruby on Rails solved
> very well: using scaffolding to provide a working out-of-the-box
> experience but then also allowing you to refine the default behaviour
> step-by-step. The way it's done in Ruby is a combination of source
> generating scripts, code generating logic in the classes itself (easy
> with a dynamic language) and also using Ruby's missing-method (that is
> called when a method is called that is not defined on the object).
>
> I have no clear solution in my head, but I think it's a place where
> Sling could improve. WDYT?
>
Not sure :) Can we first collect the possible use cases? Is one use case
to replace the json renderer completely? Or do you want to use a
different json renderer depending on the path or the resource type?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
RE: Json Rendering
Posted by "Craig L. Ching" <cc...@mqsoftware.com>.
Hi Alexander,
> -----Original Message-----
> From: Alexander Klimetschek [mailto:aklimets@day.com]
> Sent: Wednesday, June 18, 2008 8:31 AM
> To: sling-dev@incubator.apache.org
> Subject: Re: Json Rendering
>
> On Wed, Jun 18, 2008 at 2:04 PM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
> >> Something like providing a new JsonWriter component at runtime ?
> >
> > Yes, that would work. We could also have a
> JsonWriterFactory that's an
> > OSGi service, but that feels like overkill right now.
>
> Yes, I have the same feeling. I think it is a general issue:
> as the default servlets are a core feature in Sling (ie.
> simple updating of JCR content), but very often you want to
> customize the behaviour for certain properties or nodes, this
> seems like a general pattern, that yet needs to be solved.
> Having a different plugin architecture in each default
> servlet (providing custom writers, request objects etc.)
> feels like the wrong solution. Especially if you consider the
> elegant way of script/servlet resolution in Sling by using
> resource-types with inheritance etc.
>
> IMHO this is the same (development) problem that Ruby on
> Rails solved very well: using scaffolding to provide a
> working out-of-the-box experience but then also allowing you
> to refine the default behaviour step-by-step. The way it's
> done in Ruby is a combination of source generating scripts,
> code generating logic in the classes itself (easy with a
> dynamic language) and also using Ruby's missing-method (that
> is called when a method is called that is not defined on the object).
>
> I have no clear solution in my head, but I think it's a place
> where Sling could improve. WDYT?
>
You had suggested that I use a selector for my special json rendering,
would maybe allowing the user to map a rendering output to a selector in
a general way be a good way to do this? You might need to "namespace"
the selectors so that you don't collide with potential future
sling-provided selectors, but I'm not sure if that's a valid idea or not
given the fairly strict rules govering URI composition. Something like
this would help me with the JCR explorer and my need for more
information about the nodes than the current JSON rendering provides
today. Just a thought.
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
>
Cheers,
Craig
Re: Json Rendering
Posted by Alexander Klimetschek <ak...@day.com>.
On Wed, Jun 18, 2008 at 2:04 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
>> Something like providing a new JsonWriter component at runtime ?
>
> Yes, that would work. We could also have a JsonWriterFactory that's an
> OSGi service, but that feels like overkill right now.
Yes, I have the same feeling. I think it is a general issue: as the
default servlets are a core feature in Sling (ie. simple updating of
JCR content), but very often you want to customize the behaviour for
certain properties or nodes, this seems like a general pattern, that
yet needs to be solved. Having a different plugin architecture in each
default servlet (providing custom writers, request objects etc.) feels
like the wrong solution. Especially if you consider the elegant way of
script/servlet resolution in Sling by using resource-types with
inheritance etc.
IMHO this is the same (development) problem that Ruby on Rails solved
very well: using scaffolding to provide a working out-of-the-box
experience but then also allowing you to refine the default behaviour
step-by-step. The way it's done in Ruby is a combination of source
generating scripts, code generating logic in the classes itself (easy
with a dynamic language) and also using Ruby's missing-method (that is
called when a method is called that is not defined on the object).
I have no clear solution in my head, but I think it's a place where
Sling could improve. WDYT?
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Json Rendering
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Jun 18, 2008 at 2:01 PM, Christophe Lombart
<ch...@gmail.com> wrote:
> On Wed, Jun 18, 2008 at 1:51 PM, Bertrand Delacretaz <bd...@apache.org>
>> ...Note that JsonRendererServlet does not currently provide an easy way
>> to replace just the node-dumping method, we might need to refactor it
>> to make that easier....
>>
> Something like providing a new JsonWriter component at runtime ?
Yes, that would work. We could also have a JsonWriterFactory that's an
OSGi service, but that feels like overkill right now.
-Bertrand
Re: Json Rendering
Posted by Christophe Lombart <ch...@gmail.com>.
Hi Bertrand,
Thanks for the info.
On Wed, Jun 18, 2008 at 1:51 PM, Bertrand Delacretaz <bd...@apache.org>
wrote:
>
> Note that JsonRendererServlet does not currently provide an easy way
> to replace just the node-dumping method, we might need to refactor it
> to make that easier.
>
Something like providing a new JsonWriter component at runtime ?
> -Bertrand
>
Re: Json Rendering
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Christophe,
On Wed, Jun 18, 2008 at 1:42 PM, Christophe Lombart
<ch...@gmail.com> wrote:
> ...I would like to modify the Json rendering. I want to add the node path &
> name. What is the best way to extend the JsonServlet for this kind of
> requirements ?...
The JSON rendering is done by the DefaultGetServlet, which is
hardwired to use the JsonRendererServlet for .json extensions.
If you create a Servlet that extends JsonRendererServlet, and register
it in the same way than the DefaultGetServlet, with an additional
@scr.property name="sling.servlet.extensions" value="json"
it should be used for .json requests instead of the DefaultGetServlet.
Note that JsonRendererServlet does not currently provide an easy way
to replace just the node-dumping method, we might need to refactor it
to make that easier.
-Bertrand