Hi Edy, I don’t enough about requirejs to make an educated answer on this part so my answer is only about the new proposed format. PROs: * possibly a bit better for end users CONs: * not restful (I think) * we mix the resource name with the rest of the URL (semantic mixing) * by mixing the resource name with the rest of the URL we need to reparse the URL to reconstruct the resource name Let me give more information by what I mean on these last 2 points. Right now when we have a URL our ExtendedURL class parses the URL by parsing the path portions and storing them into a List. So if we have http:////path1/path2/path3, we get [“path1”, “path2”, “path3]. If we wish to get the resource name we need to [“path1”, “path2”, “path3].join(“/“). In addition I also find it more logical that the resourcename be a BLOB for which we don’t know the structure (whether it’s separated by “/“ or “.” or anything else, we shouldn’t care about). The way we load the resource is by doing a ClassLoader.getResourceAsStream(resourceName). Said differently it’s by pure chance that we have both “/“ for loading a classloader resource and as a separator for a URL! So I don’t want to block your proposal but it’s seems we’re mixing apples and oranges and I’m not sure it’s a good thing. I’m curious to know what others think. Thanks -Vincent On 3 Apr 2015 at 18:39:09, Eduard Moraru (enygma2002@gmail.com(mailto:enygma2002@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.