On Wed, Jun 18, 2008 at 3:58 PM, Felix Meschberger <[EMAIL PROTECTED]> 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 <[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] > > > > >
