Hi Jim, Jim White schrieb: > Hi gang! > > The way I'd like to provide path mapping for classes is with JAX-RS > (Jersey) annontations.
Support for this would be a great addition to Sling IMHO. > > That should be pretty straightforward for compiled bundles, but I think > it can work for scripts too (at least Groovy scripts anyhow). For scripts (in general) it is a bit more problematic and I think a different problem scope. Let me take a quick tour how Sling works. Sling internally manages a so-called Resource Tree which primarily consists of the JCR Workspace on which Sling operates plus extensions: The extensions are resource which may be mapped into the tree, such as Servlets provided in Bundles: According to the Servlet Configuration, the location(s) of the Servlets in the resource tree is calculated. This same mechanism may be applied to any class using JAX-RS annotations. Now, scripts are generally just stored at the correct location in the resource tree and thus selected straight forward. This is the case of JSPs or Servlets stored in the repository and also Groovy scripts by default. Of course, we could provide Groovy scripts (Classes or Groovlets) in a bundle and annotate those scripts and register them, such that they would be mapped into the resource tree. > > I just started using Sling and don't my way around at all yet, so this > comment is probably entirely off the topic of this proposal. Probably yes. But it is touching another interesting subject, namely support for JAX-RS in Sling. Regards Felix > > Jim > > Felix Meschberger wrote: > >> Hi all, >> >> Prompted by Shane Johnson's comments on the naming conventions for >> servlets in the repository [1], I come to think, that there might be >> another solution or way to look at it. >> >> Currently a script must basically be named according to the following >> convention: >> >> [ selector "." ] method | >> [ selector "." ] extension | // GET only >> selector // GET html only >> >> All matches are done case-sensitive. This works find with general >> scripts, which may have as many dots in the file name as we like. For >> Servlets (stored in the repository) it is more problematic, since class >> files must be named after ther class name and class names are not >> allowed to have dots in it. >> >> To workaround this, I could imagine, that we extend the convention for >> script file names: >> >> [ selector "." ] method | >> Selector method | >> [ selector "." ] extension | // GET only >> Selector Extension | // GET only >> selector | // GET html only >> Selector // GET html only >> >> (uppercase signifies camelcased name). >> >> So the request "GET /some/path.print.html" could be handled by any of >> the following scripts >> >> path.GET.jsp >> GET.jsp >> PathGET.java >> path.html.esp >> html.esp >> PathHtml.vlt >> path.gsp >> Path.groovy >> >> This would of course extend the list of checks to apply for finding >> scripts, but would certainly gelp Java developers. >> >> The drawback of this is, that the request "GET /path.PrintA4.html" might >> be handled by the same script as "GET /path.Print.A4.html". But this may >> be a hypothetical collision and problem. >> >> WDYT ? >> >> Regards >> Felix >> >> [1] http://blogs.citytechinc.com/sjohnson/?p=47 >> >> > >
