Hi all,
I have been rethinking all these and also Carsten's input on our past
discussion regarding "intelligence of a Resource". I also looked at the
API and the intentions of it again, which I summarize as follows:
Resource - The object representating some datum in Sling. This may be
a JCR Node or
Property or an OSGi Bundle resource or an OS filesystem file.
ResourceResolver - The object providing access to Resource instances
from the
application context. The ResourceResolver represents the
external view of
the Resource tree.
ResourceProvider - The object capable of representing certain data as
Resource
objects.
The ResourceResolver interface is typically implemented once. It
incorporates the logic of dealing with multiple ResourceProvider
services. ResourceProvider instances may be provided by multiple parties
outside of the scope of the ResourceResolver. The ResourceProvider
instances are the factories of Resource objects: The ResourceResolver
asks the ResourceProvider for the creation of Resource objects. That is,
Resource objects are created under the auspices of the ResourceProvider
and not of the ResourceResolver.
What this means is, that Resource objects have absolutely no means of
accessing the mechanism of how a ResourceResolver uses ResourceProvider
services to find and create Resource objects. Consequently, the Resource
cannot list children and cannot access relative resources.
Therefore I have to revert and agree with Carsten, that any such child
and relative resource accessor methods must be provided by the
ResourceResolver. Any such API on the Resource interface may always only
be defined in terms of "implemented by calling the respective methods on
the ResourceResolver object". Thus defining such an API prescribes an
actual implementation, which is not the best of all things to be done by
an API ;-) Unless we define Resource as an abstract class with child and
relative resource accessor methods already implemented.
Undisputed is the fact, that the Resource should have a link to the
ResourceResolver and not to the ResourceProvider. In this respect, the
ResourceProvider interface will have to be enhanced to take the
ResourceResolver asking for a Resource from the ResourceProvider.
Remains the question of whether we actually should provide additional
public methods and properties on an interface in a single scripting
language which is not available in any other context. In other words: Is
it ok to have a JavaScript "Resource" host object with a "children"
property not matched by a respective Resource.getChildren() method ?
Wouldn't this be too confusing ?
Regards
Felix
Am Montag, den 11.02.2008, 09:11 +0100 schrieb Carsten Ziegeler:
> Felix Meschberger wrote:
> > Hi,
> >
> > I don't like this, and here is why: By adding this method, you add
> > functionality to a single location creating the impression, that this is
> > core functionality. That is you create a JavaScript-only
> > Resource.listChildren() method. The problem with this is, that migrating
> > such code to e.g. Java or trying to create similar code in other
> > languages will create tons of issues.
> >
> > In addition, this implementation does not actually work, because it only
> > considers children of the current resource's ResourceProvider neglecting
> > any other ResourceProviders which might have "children" to the resource.
> >
> > I understand, that it is cumbersome to revert to the ResourceResolver to
> > list the children of a resource - not just in JavaScript. So I would
> > like to propose these changes to the Resource interface:
> >
> >
> > Add Methods:
> > Iterator<Resource> listChildren(); // equivalent to
> > getResourceResolver().listChildren()
> > ResourceResolver getResourceResolver();
> >
> > Remove Method:
> > ResourceProvider getResourceProvider(); // replaced by
> > getResourceResolver()
> >
> I'm not against these changes, but I think we discussed this some months
> ago when we
> discussed the Resource interface. And there were some arguments against
> doing this (which I can't remember and haven't looked up).
> I just hope that we are not going back and force with adding and
> removing method just because someone needs them somewhere.
> For now, I think adding the getResourceResolver and removing
> getResourceProvider should be sufficient. I see no real value in adding
> the listChildren method which is just a shortcut.
>
> Carsten
>
