IMHO the sling:include processing looks correct, and the GET
processing looks wrong.
I had always used the rule, perhaps incorrectly that the:
Resource URI was the path upto and not including the first . in the
last path element
which should make the resource
ie
resourcePath: /content/resource./mysuffix
extension: html
selectors: null
suffix: null
I notice the . has gone from the include, was that intentional or a
typo ?
Ian
On 25 Aug 2009, at 16:12, Branden Visser wrote:
Hi everyone,
I found some inconsistency between URL processing in sling.include
and a URL processed in an HTTP GET request.
If I do an HTTP request for the following:
/content/resource./mysuffix.html
The request is processed as:
resourcePath: /content/resource
extension: null
selectors: null
suffix: /mysuffix.html
Whereas if I do:
sling.include(/content/resource./mysuffix.html), what I get is:
resourcePath: /content/resource/mysuffix
extension: html
selectors: null
suffix: null
Judging solely by the assertions in the RPI unit test [1], the HTTP
request URL decomposition is correct, and the sling.include handler
has a bug. Unless a sling include is *not* supposed to be synonymous
with a GET request?
Best,
Branden
[1]
http://svn.apache.org/repos/asf/sling/trunk/bundles/engine/src/test/java/org/apache/sling/engine/impl/request/SlingRequestPathInfoTest.java
