Hi Vincent, On Fri, Apr 3, 2015 at 11:18 PM, vincent(a)massol.net wrote: But isn't it much more restful than the current http://localhost:8080/xwiki/bin/webjars/resources/path?value=%2F%2F ?

IMO, the ID (if this is what you refer to as resource name) should always be between 2 "/"es. If the resource name contains a "/" itself, then it should be URL escaped by the caller. If by resource name you mean the entire "value=%2F%2F" part, see below.

I am having a hard time understanding if you are talking about URL management in XWiki in general (i.e. determining what is the action that the current URL is trying to reach; is it webjars, is it view, is it bin, is it rest, etc...), or if you are talking about the actual webjar resource that the client is trying to reach (i.e. files inside the webjar). If you are talking about webjars in specific, don`t forget that they are basically zipped directories and that will not really change AFAIK. Any resource inside a webjar is basically a file in a directory. Webaps will still want to handle them as files inside directories inside the web application, not as parameters inside a URL request to some service that returns files. This is actually where the problem comes when a library such as requirejs uses and enforces this assumption.

Thanks, Eduard > I’m curious to know what others think. > > Thanks > -Vincent > > > On 3 Apr 2015 at 18:39:09, Eduard Moraru (enygma2002(a)gmail.com(mailto: > enygma2002(a)gmail.com)) wrote: > > > Hi, > > > > Currently, the webjars URL mapping is the following: > > > > http://localhost:8080/xwiki/bin/webjars/resources/path?value= > > %2F%2F > > > > Example: > > $services.webjars.url('codemirror', 'lib/codemirror.js') > > returns > > > http://localhost:8080/xwiki/bin/webjars/resources/path?value=codemirror%2F5… > > > > The problem with this is that require modules that use relative paths for > > their dependencies are broken because of the URL mapping we use, more > > specifically by the "?" character inside the URL we use. > > > > A concrete example is the CodeMirror webjar that defines its own modules > > which express their dependencies relatively: "../../lib/codemirror" > > > > Here we have a problem, since if we directly depend on > > "$services.webjars.url('codemirror', 'mode/css/css.js')", the module will > > fail to find its relatively defined dependency. > > > > One approach would be to define paths, so that requirejs can work its > magic: > > > > require.config({ > > paths: { > > cm : " > > > http://localhost:8080/xwiki/bin/webjars/resources/path?value=codemirror%2F5… > > " > > } > > }); > > > > require(["cm/lib/codemirror", "cm/mode/css/css"], function (CodeMirror) { > > console.log(CodeMirror); > > }); > > > > This properly finds "/lib/codemirror.js" and "mode/css/css.js" that we > > explicitly request, however, the internal dependency of css.js fails to > be > > found at the resolved URL " > > > http://localhost:8080/xwiki/bin/webjars/resources/path?value=codemirror%2F5… > > ". > > > > Requirejs does not add the ".js" extension to the resolved path because > the > > resolved path contains a "?" character so it is considered an absolute > URL, > > not a relative path. > > > > The proposal is to stop using this URL mapping, since it is awkward to > have > > paths in parameters and, instead, use a more intuitive one that is both > > good for clients and for requirejs. > > > > The proposed mapping/scheme is: > > > > http://localhost:8080/xwiki/bin/webjars/// > > > > Any additional parameters that we might need for the webjars action would > > be appended at the end. There is currently 1 case that I know of, which > is > > "evaluate=true|false". > > > > Without this change, I can not find any solution to using a webjar such > as > > CodeMirror that uses relative defined modules. > > > > Thanks, > > Eduard > > > > P.S.: Any additional advice on using requirejs to circumvent this > > limitation is most than welcomed.

Hi, On Sun, Apr 5, 2015 at 10:52 AM, vincent(a)massol.net &lt;vincent(a)massol.net&gt; wrote: I guess the same can be said about "http://<server>/xwiki/rest/<resourceURIPart>". You have to know the *endpoint* of the API you are accessing, whether it's a REST resource, a webjar resource or anything else, depending on the resource type, there is a particular endpoint associated with it that you need to know. I find that perfectly acceptable :) The same mention about "/" path separator probably applies for the REST API again. Thanks, Eduard

On 04/04/2015 01:46 AM, Eduard Moraru wrote: Don't forget that escaped / is not allowed in URLs by default by both HTTPD and Tomcat.