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 <[EMAIL PROTECTED]> > wrote: > > > Alexander Klimetschek wrote: > > > >> On Wed, Jun 18, 2008 at 2:04 PM, Bertrand Delacretaz > >> <[EMAIL PROTECTED]> 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 > > [EMAIL PROTECTED] > >
