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]
