[
https://issues.apache.org/jira/browse/SLING-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762961#action_12762961
]
Alexander Klimetschek edited comment on SLING-864 at 10/7/09 2:32 AM:
----------------------------------------------------------------------
@Carsten: could you also add the test cases that are included in my original
patch? Thanks!
And we should update the documentation, ie.
http://sling.apache.org/site/url-decomposition.html. I could do it, but I don't
have write access.
was (Author: alexander.klimetschek):
@Carsten: could you also add the test cases that are included in my
original patch? Thanks!
> Parse path info for NonExistingResource
> ---------------------------------------
>
> Key: SLING-864
> URL: https://issues.apache.org/jira/browse/SLING-864
> Project: Sling
> Issue Type: Improvement
> Components: JCR
> Affects Versions: JCR Resource 2.0.4
> Reporter: Alexander Klimetschek
> Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.0.6
>
> Attachments: SLING-nonexisting-pathinfo.patch
>
>
> As proposed on the mailing list http://markmail.org/message/52m32zh36ewo4xl2,
> it would be helpful if the sling:nonexisting resource type would support
> selectors and extensions similar to normal resources.
> Currently you can only register one servlet per HTTP method for nonexisting
> resources. For example, this makes it impossible to add multiple importer
> servlets, that import different file formats into the repository at
> non-existing locations (they would create the necessary path). It would be
> good to register them on an extension-basis, eg. to do a POST to
> /content/calendar.ics for an icalendar file, a POST to /content/i18n.xliff
> for an xliff file, etc., with one servlet handling each import.
> Important to note is that until now, the contract of the NonExistingResource
> case was that sling did not try to parse anything and simply return the full
> URL as the resource path - even if it contains dots at the end. Selectors and
> extension in the request path info were always null. The sling post servlet
> for example relies on that by using the path to create a real resource there.
> Since this is already part of the released API, changing that contract is not
> really an option.
> In a f2f discussion with Felix and Carsten we came up with the solution to
> keep the full path for the nonexisting resource path but additionally try to
> parse the selectors and extension. This will make the script resolution work
> just as for existing resource while not breaking the existing contract.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
