Hi,
Reminder: since we will start using more and more require.js, we need a
solution for optimizing [1] the requireJS javascript code because otherwise
we will end up with way too many HTTP requests for each individual
requireJS module.
Thanks,
Eduard
----------
[1]
On Sun, Aug 2, 2015 at 1:55 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
Hi Thomas,
On 2 Aug 2015 at 12:15:37, Thomas Mortagne (thomas.mortagne(a)xwiki.com
(mailto:thomas.mortagne@xwiki.com)) wrote:
On Sat, Aug 1, 2015 at 11:08 PM,
vincent(a)massol.net wrote:
> Hi devs,
>
> I’d like to propose the following official future organization for our
javascript/CSS code.
[snip]
WDYT?
I agree this looks better from runtime/extension point of view.
However it will make working on these resources a lot more painful
(right now you modify it and just refresh).
That’s a good point. BTW I have a similar problem today: for example we
provide two versions of xwiki.js, one xwiki-min.js and one xwiki.js.
However both versions are minified. We should provide a non minified one
for when we pass minify=false in the query string.
We could do something like:
* Bundle 2 versions in the JAR: a minified one and a non-minified one.
* At runtime, somehow group all js files located in all webjars into a
single minified js file (yuicompressor). We’re doing this for JSX so we
should be able to implement this for webjars too. Something like a JVM JIT
for JS files.
* When the WebJarsResourceReferenceHandler is used to access a webjar
resource, if minify=false is specified in the URL, copy the non-minified
resource somewhere on the filesystem (probably in the data dir for now) and
return it. If the resource already exists on the FS, serve it from there
and don’t extract it from the JAR. This would allow devs to make changes to
that version and see the result, and also to debug easily JS in the browser.
[snip]
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs