Today we encountered a strange behavior of SSJS when computing URLs to the current database's path for resources in the application. In this case I wanted to compute the src-property of an output script block.
There is a simple solution / a way to do it right without getting into that mess, but first I want to show you what my approach was and how it made me stunning.
On my XPage I compute the URL of the src-property of an output script like
This code is my test page and shows 3 different approaches to compute the URL to a Javascript resource in my application:
The first two methods produce some strange output under certain circumstances I want to describe here in detail
Assuming the application lays in a folder called TEST (capitals) und your URL in the browser uses also capitals for that folder you'll get a result like this
Look at the 3 script-blocks, the URLs are ok.
If you change the URL in the browser to any other writing of the foldername (e.g. all lowercase) you'll receive something like this:
Domino produces BOTH values (the requested URL and the original path with capitals). I tested this with a script in a beforeRenderResponse event - which does NOT produce this kind of output. Only if you compute a property like in this case the return values are "doubled".
The 3rd output is generated without using the computation via SSJS functions at all.
Conclusion
If you just want to point to a resource that resides within the same database you can use "/resource.whatever" as the value as XPages applications always compute from the context they reside in - and that's the database level.
I don't know if this is a PMR - maybe it's just the behavior I'd have to expect from now on. If you know better please enlight me and put your explanation in the comments.
Jesse Gallagher has another interesting post about URLs in XPages as well.