[ https://issues.apache.org/jira/browse/SLING-2726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13575682#comment-13575682 ]
Carsten Ziegeler commented on SLING-2726: ----------------------------------------- I think this would be a little bit against the general principles of Sling where we a request is targeting a resource and once the resource is found in the tree, a script is called to generate the response for this resource. Sure, right now we have this mechanism which allows you to mount a servlet at some specific path, but this servlet is mounted as a resource into the resource tree and it returns the correct resource type so the servlet is then also picked by the script resolution. So, although a little bit stretched, the resource resolution mechanism and rendering still works following the basic principles. If we would allow a Sling servlet to be mounted through a wild card, this would get more blurry. So I think, if you want to represent your data (profiles) as resources, a resource provider is the way to go; it's very simple to implement. Another option would be to register your servlet outside of Sling directly with the http service. I think it depends on the exact use case which way is the better one > allow simple wildcards in servlet paths > --------------------------------------- > > Key: SLING-2726 > URL: https://issues.apache.org/jira/browse/SLING-2726 > Project: Sling > Issue Type: Improvement > Components: Servlets > Reporter: Nicolas Peltier > Priority: Minor > > While i'm a big fan/evangelist of sling unique servlet management. I tend to > think this would be nice to allow minimum wildcard for servlet paths, i.e. > /a/b/* (no suffix), as some use cases can't be cover right now with jcr based > resources + path servlets. > Basically every resource model where you don't need a jcr node for (while > it's very convenient most of the time). > I'm thinking for example of having a profile servlet with a nice public > /profile/jdoe.html url. Right now my possibilities are > * to create a flat tree of fake user nodes under a profile node just for the > sake of my urls (don't need righs handling, don't need other verbs for the > same resource), > * to have tons of vanityUrls (not meant for that kind of usage) > * to create my own ResourceProvider that map that kind of URLs to existing > jcr resources. > * to switch to /profile.jdoe.html, or /profile.html?uid=jdoe > And i tend to think a tiny wildcard in a path parameter would be nicer :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira