On Thu, Feb 12, 2009 at 8:39 AM, Felix Meschberger <[email protected]> wrote: > Using the absolute path mechanism you can do that: just register the > servlet for two paths, say: > > /apps/sling/nonexisting/i18n.servlet > /apps/i18n/dictionary.servlet > > This should do the trick. I fear, though, that selectors and extensions > are no supported on non existing resources, since Sling does not apply > wild guessing (any more) as to how long the resource path is and where > selectors and extensions start.
Thanks, I got it now working. But with sling/nonexisting I face a serious problem now: since it does not parse any extension or selectors, the servlet resolution for it will also only allow for exactly one POST servlet: /apps/sling/nonexisting/POST.servlet (also exactly one for GET, PUT etc.). Using an extension or selector in that servlet path, eg. /apps/sling/nonexisting/POST.ics.servlet, does not work, because Sling won't even pick it up. This makes the sling/nonexisting not very flexible, because you can only have one to handle it, even the OptingServlet does not help, because the list of candidates will only contain the "winner" of the /apps/sling/nonexisting/POST.servlet path + the webdav servlet as fallback. But I think it is feasible to allow for different "importer" servlets that act on the extension (or additionally selectors), eg. importing /content/translations.xliff, /content/calendar.ics, /content/whatever.ext. Therefore I would suggest to "turn around" the non-existing path parsing case and instead of assuming the full URL to be the resource path and setting selectors and extension to null, just use the part after the last "." as extension and the previous parts as selectors. If you want a different handling, you can still register for sling/nonexisting and create a resource based on the full path anyway - sling would not force what resource you create, only how the servlets are resolved. WDYT? Regards, Alex -- Alexander Klimetschek [email protected]
