Hi,
Another option could be (as proposed elsewhere) a new method
<T> T ResourceResolver.adaptTo(Class<T> type);
so we could:
Session s = request.getResourceResolver().adaptTo(Session.class);
or
ObjectMapper om =
request.getResourceResolver().adaptTo(ObjectMapper.class);
WDYT ?
Regards
Felix
Am Montag, den 10.12.2007, 12:28 +0100 schrieb Carsten Ziegeler:
> Felix Meschberger schrieb:
> > Hi Carsten,
> >
> > Thinking about this ResourceManager and taking into account the recent
> > changes we introduced to the Resource interface (replacing getRawObject
> > and getObject by the adaptTo method), I would even take a further step:
> > We made the JCR dependency an implementation detail by not providing a
> > getNode() or getItem() method. In the same spirit we should make object
> > mapping an implementation detail.
> >
> > As such I propose to drop the ResourceManager interface alltogether in
> > the Sling API.
> >
> > In the Sling jcr/resource implementation we will have this mapping
> > support and we may introduce such a helper for example as a request
> > attribute or on-demand through a factory method of the
> > JcrResourceManagerFactoryImpl (to be renamed of course to
> > JcrResourceResolverFactoryImpl) as
> >
> > ObjectMapper getObjectMapper(Session session);
> >
> > microsling has no object mapping and thus no such feature.
> >
> > WDYT ?
> >
> Hmm, yes makes sense - would it be possible to make the ObjectMapper
> available through the ServiceLocator? I think that's a little bit more
> convenient than storing it into an request attribute.
>
> Carsten
>
>
