> On 20 Jun 2016, at 15:12, Julian Sedding <[email protected]> wrote: > > IMHO your NonExistingResource or SynthetricResource should already > have the correct absolute path.
This is not possible, as resource resolving on SyntheticResources is not unambiguous. So basically the SyntheticResource would need to know about all possible resource locations (may easily be more than one). Unfortunately the ResourceResolver does not provide a method to return all possible resolved paths. > As Rob noted, RR.resolve() is about > resolving URIs to Resources. Once you are navigating Resources (e.g. > getParent()), no more resolve() calls should happen. At least trying out the possible resource paths is necessary during getParent(). > > From my point of view the problem is that the mapping (/ -> /content/) > is not applied when the URI is resolved. I would expect that you get: > > nonExistingResource.getPath() -> > "/content/existingParent/nonExistingResource" (IMO getting > "/existingParent/nonExistingResource" here is a bug) > nonExistingResource.getParent().getPath() -> "/content/existingParent" > (exists) > > What would be involved in fixing the (IMO) correct resolution of the > "nonExistingResource"? Basically it would require to refactor the ResourceResolverImpl a bit to be able to get all possible resource paths (independent on whether the actual resource does exist or not). Basically all those potential paths have to be given once a SyntheticResource is constructed then and evaluated in case getParent() is called. Not sure this will work in all cases though, as the logic in https://github.com/apache/sling/blob/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverImpl.java#L271 <https://github.com/apache/sling/blob/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverImpl.java#L271> is really convoluted and even involves some recursion which cannot be reflected when just acting on Strings instead of Resources. > > Regards > Julian > > On Fri, Jun 10, 2016 at 5:12 PM, Konrad Windszus <[email protected]> wrote: >> I am talking about >> https://github.com/apache/sling/blob/c9e59667d8f9cd698bc33a51f3e6a22e85d4a952/bundles/scripting/sightly/engine/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L254 >> >> <https://github.com/apache/sling/blob/c9e59667d8f9cd698bc33a51f3e6a22e85d4a952/bundles/scripting/sightly/engine/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L254> >> here. >> The best would be if the SyntheticResource would optionally get a list of >> possible resolved resource locations. If we add another constructor taking >> an additional List<String> with possible resolved repository paths we would >> be able to consider that list in the getParent(). >> That way we would not directly rely on ResourceResolver.resolve() within >> getParent() but just try getParent() for the different possible repository >> paths until we find a matching one, or if we don't find a matching one >> return a NonExistingResource(), again being feeded with the same list of >> possible resolved repository paths. >> WDYT? >> Konrad >> >> >>> On 10 Jun 2016, at 10:13, Carsten Ziegeler <[email protected]> wrote: >>> >>> Konrad Windszus wrote >>>> My use case is AEM: >>>> I have an existing page containing some components (each one encapsulated >>>> in dedicated child resources). >>>> Now the underlying template in AEM is extended (i.e. new fixed components >>>> have been added). For each of those a child resource is necessary, which >>>> does not exist yet on older pages (being created at a point in time, where >>>> the template did not have that component yet). >>>> >>>> In Sightly we include those new components via data-sly-use with an >>>> explicit resourceType. Sightly will first try to get the child resource >>>> with that path. If it does not exist yet it will create a >>>> SyntheticResource with the given resource type. >>>> For example to get the cloud service configuration we would need to get >>>> the (existing) container AEM page for the SyntheticResource. This >>>> currently fails, because of the issues mentioned. >>>> >>>> If this would work, the component would be rendered fine (even acting on a >>>> SyntheticResource). >>> >>> Ok, so I guess this can be easily solved in Sightly as this sounds to me >>> like a Sightly use case. >>> >>> Carsten >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> [email protected] >>
