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 ([email protected](mailto:[email protected])) 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.1/lib/codemirror.js > > 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.1 > " > } > }); > > 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.1/lib/codemirror > ". > > 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. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
