On Mon, Sep 14, 2009 at 1:59 PM, Vidar Ramdal <[email protected]> wrote:
> On Mon, Sep 14, 2009 at 1:41 PM, Bertrand Delacretaz > <[email protected]> wrote: > > Hi, > > > > On Mon, Sep 14, 2009 at 12:22 PM, Marc Speck <[email protected]> > wrote: > >> On Mon, Sep 14, 2009 at 11:43 AM, Bertrand Delacretaz > >> <[email protected]> wrote: > >>> ...using version.12 instead of version=12 should help here, 12 > >>> then becomes just another selector. > >> > >> Excellent idea, parsing getSelectorString() should give the number. I > have > >> also /foo/bar.version.12 for folders but it's fine to look into the > >> extension for the number. > > > > You don't even need to parse if you use > > SlingHttpServletRequest.getRequestPathInfo().getSelectors(). > Right, but if the order should ever get mixed up in the future, the algorithm is more likely to fail then parsing "....version.123.....". > > > >> ...The OptingServlet sounds interesting. It means that I can register > several > >> servlets for the same resourceType and implement accept() accordingly?.. > > > > Yes, that's the idea, for those (hopefully rare) cases where the other > > mechanisms aren't sufficient. > > Yeah, do what Bertrand says - I didn't think about the OptingServlet > when replying to your questions. Seems it can do pretty much what you > want. > I'd need it for the main resourceType that handles 70% of traffic. It seems that SlingServletResolver does not cache OptingServlets which makes sense. However, I will have to investigate how much performance I loose with giving up servlet caching. A custom ResourceCollector.hashCode could probably solve the problem but this goes too far for me. I'm rather considering creating 3 subResourceTypes just for servlet resolving. As JCR queries are inheritance-sensitive to type constraints, I think it's the solution with the least side effects. Thanks for your suggestions, Marc
