4 Apr
2015
4 Apr
'15
7:46 a.m.
Hi Vincent,
On Fri, Apr 3, 2015 at 11:18 PM, vincent(a)massol.net <vincent(a)massol.net>
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&…
?
* 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 (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.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs