Hi Vincent, On Fri, Apr 3, 2015 at 11:18 PM, [email protected] <[email protected]> wrote:
> 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) > But isn't it much more restful than the current http://localhost:8080/xwiki/bin/webjars/resources/path?value=<id>%2F<version>%2F<filePath> ? > * we mix the resource name with the rest of the URL (semantic mixing) > 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=<id>%2F<version>%2F<filePath>" part, see below. > * 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 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 ([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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
