Hi,
We may have talked about this before, but I can't remember doing so.
The current resource resolution scheme is based on locating a
ResourceProvider for a given path and asking that ResourceProvider for
the Resource. We do that by retrieving a list of ProviderHanders (that
wrap ResourceProviders) from a tree of ResourceProviderEntries.
ie:
given a root resource provider called rootRPE, the list of
ProviderHandlers for the path /a/b/c/d is retrieved by performing
rootRPE.get("a").get("b").get("c").get("d").values() (performed inside [1])
where values() is Collection<ProviderHandler> and
ProviderHandler.getResource(...., path) returns the Resource.
There is some logic surrounding the cases where the list of Providers
generates no matches and how the search continues, but that might not
be used.
My question is:
Would an alternative form of resolution be better?
Would registering ResourceProviderEntries using a list of regexes as
many other frameworks do which might make the tree considerably
smaller and more flexible. I think the last time I did a test regex
performance once constructed was as fast as this type of nested map
lookup.
Initially the change might just require changing the implementation of
[1], and converting the registration from key lookups to patterns.
WDYT?
Too risky and unnecessary given the request handling already present in Sling ?
Something worth doing ?
Something better placed to do inside a ResourceProvider ?
Already present somewhere else in Sling ?
Ian
(BTW, I dont have a specific use case driving this other than,
re-reading the code base in this area and having used regex based
registration of "providers/handlers" in other frameworks)
1
org.apache.sling.resourceresolver.impl.helper.ResourceIterator.getResourceProviders(String,
Set<ProviderHandler>)
