Ian Boston wrote: > On 14 Dec 2009, at 13:51, Carsten Ziegeler wrote: > >> Ian Boston wrote: >>> I think the provider implementation should make the decisions on exactly >>> how it decides its a resource type it knows about. >>> >>> One might use a rule like "starts with /myapp" >>> but others might use "has a parent node with sling:resourceType sling/album" >>> >> Hmm, do I you mean if I use the jcr resource provider I, the logic >> should be part of the jcr resource provider and if I'm using the file >> provider I should be able to add some logic there? > > Yes. > However I think it needs to be clear in the documentation for the API that > anything implementing this interface must > expect to be presented with paths that the implementation will not want to handle, and in those cases the implementation > must add an absolute bear minimum of processing overhead. (if fast low cost exit for non matching resources), as *all* > providers could be invoked for all potential resources. Yes, and I think this somehow defeats separation of concerns - my application would need to know into which providers it has to plugin itself. The application shouldn't know such things.
> > if however you think the number of selection methods is small and we can > capture them all in the "driver" code that > invokes the provider, then we might be able to use a lookup mechanism. I am doubtful that we know a sufficiently > wide spectrum of use cases to do this. Yes, that's true - and I have to good idea how to make an interface out of this either. In the case of JCR this was easy: we just passed in the node and the implementation can do whatever it wants. In the general case we have nothing except the path - way have everything we need to construct a resource object...except the resource type. Maybe taking your road and configuring each used provider accordingly is in the end the easier solution. However we don't have such support in the file system provider yet :) Regards Carsten -- Carsten Ziegeler [email protected]
