[
https://issues.apache.org/jira/browse/SLING-2726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13578182#comment-13578182
]
Felix Meschberger commented on SLING-2726:
------------------------------------------
I am inclined to accept this request. The change is really minimal and we just
have to improve on the ServletResourceProvider.getResource method: This
currently checks for path equality. With "wildcard" or "prefix" support we
would check for prefix equality.
We could implement this requiring an additional service property to be set such
that existing servlets are still handled with equality test only, while new
implementations may request the new behaviour.
> 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
