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 ?
Regards
Felix
Am Freitag, den 07.12.2007, 12:41 +0100 schrieb Carsten Ziegeler:
> Hi,
>
> I think we should not let the ResourceManager extend the
> ResourceResolver as this complicates its usage.
> If you want to get the ResourceManager you currently have to get it from
> the request via the getResourceResolver() method and then try to down
> cast it.
>
> If we are in an OSGi environment and you want to implement a service
> depending on the resource manager, you have to depend (bind) the
> resource resolver and test if it is a resource manager. This is a little
> bit ugly as you just want to use a resource manager.
> As the resource manager gets a Resource object via its method I think we
> can decouple the interfaces without any problems.
>
> I currently see no benefit in extending the resource resolver for the
> resource manager. Therefore I propose to make it a standalone
> interface/service and add a getResourceManager() method to the sling
> request which might return null if no resource manager is available.
> Or, if we don't want to add the getResourceManager() method, one can get
> the resource manager through the service locator (which is fine for me
> as well).
> In addition we should perhaps think of a better name than resource
> manager...
>
> Carsten
