Ian Boston wrote: > > On 14 Jul 2009, at 12:51, Bertrand Delacretaz wrote: > >> Hi, >> >> On Tue, Jul 14, 2009 at 1:39 PM, Carsten >> Ziegeler<[email protected]> wrote: >>> Felix Meschberger wrote: >>>> (5) Move the o.a.s.api.adapter package to the Sling Adapter module >>>> (which also contains the AdapterManager implementation and the >>>> SlingAdaptable class. Thus the Sling Adapter module would not import >>>> from the Sling API anymore. Instead the Sling API would import from the >>>> Sling Adapter Module. As a consequence the SyntheticResource could >>>> extend the SlingAdaptable class. >>>> >>> i think we should keep the API self contained and try to not depend on >>> other parts. >>> >>> On the other hand I agree that there might be use cases where adapting a >>> synthetic resource makes sense.... >> >> Agreed >> >>> ... So what about leaving everything as is and return where >>> appropriate sub >>> classes of SyntheticResource which have a proper adaptTo() >>> implementation.... >> >> Sounds good to me, but how would one do that in practice? >> >> Say I want to return my own SyntheticResource subclass for nonexisting >> paths that look like /content/blog/**/comments, how would I do that? Hmm, I don't want to do this based on the path or any other "volatile" information. I think the component that is currently creating the synthetic resource should just always create a synthetic resource sub class with a proper adaptTo implementation. I haven't looked in detail yet, where this is exactly happening.
> > :), > I think I asked something similar a few weeks back. > There is a patch that changes the JcrResourceResolver2 to allow plugins > to generate ResourceTypes for non existent paths, however the patch > isn't really acceptable since it make NonExistentResource non final. I > have been thinking that instead it should be doing something with > SyntheticResource since thats what NonExistentResource extends. > > Perhaps the point at which JcrResourceResolver2 generates the > NonExistentResource, plugin implementations should be given the chance > to create a SyntheticResource, around line 237 of JcrResourceResolver2.java Hmm, I think these are two different (while slightly related) issues :) The original issue in this thread is about having a better implementation of adaptTo in a synthetic resource (currently it always returns null) - this is a generic approach we could solve in one general place. Your concern is more application specific and requires some kind if plugin mechanism - I'm not against your idea, but so far I see the use case for the first thing :) Maybe we can come to a solution for both use cases. Carsten -- Carsten Ziegeler [email protected]
