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 <[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] >
