Hi Ian, 2009/6/2 Ian Boston <i...@tfd.co.uk>
> AFAICT its impossible to virtualize paths (URI wrt JCR path) using this > approach in the JCR. > > Unfortunately for me, its a use case I can't ignore as we have lots of > situations where a non listable could contain millions of items. > Back to square one. > > >>> The current design and intention is, that for any one (root) path there >>> may only be one resource provider registered. So for example, for a >>> (root) path "/some/path", there may only one. Of course there may be >>> another one at "/some" or at "/some/path/below". >>> >>> I want to be able to bind a special Resource to a node with a >> corresponding resourceType (created by the application) anywhere in the >> content system, so that all the standard Sling processing can access that >> Resource. >> >> For example: >> I want to be able to create a node anywhere in the content system, and >> under that node have a hashed store that is managed as if the entire node >> space was flattened. >> >> eg >> the URL >> /x/y/z/store/12312312/a/b/c >> is mapped to JCR space >> /x/y/z/store/content/aa/bb/cc/dd/12312312/a/b/c >> >> using the ResourceProducer mechanism. >> > Can you go into some more detail regarding the requirements for this strategy? Could you use node representations in store to placehold/redirect to the nested content at "content/aa/bb/cc/dd/"? Regards, Paul Noden
