> We could provide a way through the ResolveContext to get the "parent" > provider and check that one for a resource.
I think that should work for these cases, yes. This would make any cascading the responsibility of the ResourceProvider implementation, similar to how servlet filters work. Regards Julian On Mon, May 18, 2015 at 4:27 PM, Carsten Ziegeler <[email protected]> wrote: > Am 18.05.15 um 16:11 schrieb Julian Sedding: >> Hi Carsten >> >> Overall I welcome a cleanup in this area, so +1. >> >> I have some concerns about the provider always owning the root, >> however. I understand that this makes it easier to have good >> performance by default. But I also believe that there are use-cases >> where it is desirable to enhance a resource tree that is predominantly >> provided by another provider. E.g. add a child resource called >> "accessStats" blow every resource of type "page", or the >> {{SuperimposingResourceProvider}}. >> >> How could these scenarios be implemented? Maybe they could proxy all >> calls, but this would require that they can easily query "all >> providers except themselves". But then all calls would be proxied, >> potentially leading to multiple layers of delegation. >> >> Maybe someone else has a better idea?! >> > Of course we can keep the current flexibility to select whether the > provider owns the root. > However I would prefer to not have this flexibility anymore. > We could provide a way through the ResolveContext to get the "parent" > provider and check that one for a resource. > > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected]
