Hi,
Yes, adapters always (currently) rely on the functionality supported by
the concrete implementation. This is the case for both the
Resource.adaptTo() as well as for the proposed
ResourceResolver.adaptTo() method.
Of course, we could conceive a more flexible approach as implemented in
Eclipse, where there is an Adaptable interface defining the adaptTo()
method and some functionality for implementing configurable adaptors
exist. Not sure, whether we this for Sling, though.
Regards
Felix
Am Montag, den 10.12.2007, 14:30 +0100 schrieb Carsten Ziegeler:
> Felix Meschberger wrote:
> >
> > Not sure whether I understand you correctly. Thing is that the adaptTo
> > method just returns an object of the requested class (or null if not
> > possible). It is by no means required, that the adaptTo method returns
> > this cast to the correct type. So, the implementation may possible by:
> >
> > public <T> T adaptTo(Class<T> type) {
> > if (type == Session.class) {
> > return (T) getSession();
> > } else if (type == ObjectMapper.class) {
> > return (T) getObjectMapper();
> > }
> > return null;
> > }
> >
> > private ObjectMapper getObjectMapper() {
> > if (objectMapper == null) {
> > objectMapper = new ObjectMapper(getSession());
> > }
> > return objectMapper;
> > }
> >
> > I do not think, that we run into any extension problems using this
> > approach because the ObjectMapper and the ResourceResolver are not
> > necessairily the same.
> >
> Ok, these might not be the same classes, but the service used as the
> resource resolver needs to "know" all possibilities for "adaptTo" and
> needs to do the correct stuff.
> So, if we have two possibilities for adaptTo, you can think of four
> possible implementations - one not supporting the extensions at all, one
> support both and two each supporting just one extension.
>
> I'm not sure if this is just a theoretical problem, but it seems to me
> that this might cause trouble over time.
>
> Carsten
>
