On 05/04/2013 09:28 AM, Vincent Massol wrote:

On May 3, 2013, at 3:41 PM, Denis Gervalle <[email protected]> wrote:

...

On Thu, May 2, 2013 at 2:53 PM, Vincent Massol <[email protected]> wrote:

...

Hi devs,

ATM the solution is described here: http://dev.xwiki.org/xwiki/bin/view/Community/Debugging#HDebuggingJavaScript

What would you think about doing this instead: * Package both the minimized and the non minimized version in our WAR (it shouldn't add too much weight to our overall WAR size) * Have a directory structure like this:

resources/.../<module>/ |_ <non minified js file here> |_ min/<minified js files here>

* This would allow to put in our xwikivars.vm something like (pseudo code):

#if ("$!request.minify" == 'false') #set ($jsDir = '/') #else #set ($jsDir = 'min/' #end

* Then everywhere we reference JS files we use $jsDir. For example in attachmentsinline.vm:

$xwiki.jsfx.use('uicomponents/widgets/${jsDir}upload.js', {'forceSkinAction': true, 'language': ${xcontext.language}})

This assumes that everywhere we reference js files is always in velocity, which is not true. I can think of at least one place, the dashboard macro ( https://github.com/xwiki/xwiki-platform/blob/e7c3855397bee00a5f1fe8b6fe9da60... ). Now, I admit that one might not be the cleanest code ever, but I wonder what would stop anybody from wanting to include a resource from java or, say, groovy?

...

...

…

This would allow to remove the "debug" profile and make it much faster to debug XWiki issues, even in production systems.

WDYT?

Looks great, would be even better if the same option were passed automatically for JSX as well, which would ensure that all JS are not minified. This is already the case and that's why I chose the "minify" request parameter name :)

See the following in AbstractSxAction.java:

if (BooleanUtils.toBoolean(StringUtils.defaultIfEmpty( request.get(COMPRESS_SCRIPT_REQUEST_PARAMETER), "true"))) { extensionContent = sxType.getCompressor().compress(extensionContent); }

indeed, but this uses the parameters of the URL to the js (the jsx action URL). not the params of the page that demands the js. Which means that if you want to debug a page, you'd have to figure out all the scripts that the page is using, and make sure you add, one way or another, the minify=false parameter. Also, it works if you load the jsx onDemand (when you'd be able to, say, request the jsx and add the {"minify": false} parameter), but it won't work for the automatically loaded jsx like "always on this wiki" or "always on this page". Also, adding this minify parameter to the call could be a pain, because you might not know which is the script that is loading the jsx, you have to go look for it, etc. In the light of these 2 (3) things, it could maybe be nicer with some sort of a preference or so, although serving 2 different js for the same URL is not friendly with the browser cache. I need to think a bit more thorough to come up with an idea about how to make it better from this point of view. Anca

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On 05/14/2013 08:57 AM, Guillaume "Louis-Marie" Delhumeau wrote:

Hi devs,

Can't we rewrite all JSFX URLs with a suffix when $request.minify is set to false?

I mean, when the developer do $xwiki.jsfx.use('uicomponents/widgets/upload.js'), the JSFX module actually add 'uicomponents/widgets/upload_full.js' to the webpage, if the file exists?

There will be no cache problem, and it is easy to implement.

it could work, yes, I thought about the jsfx/jsx modifying the URL but what I don't like that much about this solution is the fact that the sent file will not correspond anymore to the file demanded by the developer that did the include. This can be troubling, and could also have some dirty side-effects, because it's automatic and magic. Also, we still would need a solution for jsx, knowing that in the case of the jsx there is no file. We could invent a new action, jsxdebug, for example. This could also work for jsfx/jsrx maybe... Anca

Louis-Marie

2013/5/13 Anca Luca <[email protected]>

...

On 05/04/2013 09:28 AM, Vincent Massol wrote:

...

On May 3, 2013, at 3:41 PM, Denis Gervalle <[email protected]> wrote:

On Thu, May 2, 2013 at 2:53 PM, Vincent Massol <[email protected]>

...

wrote:

Hi devs,

...

ATM the solution is described here: http://dev.xwiki.org/xwiki/**bin/view/Community/Debugging#** HDebuggingJavaScript<http://dev.xwiki.org/xwiki/bin/view/Community/Debugging#HDebuggingJavaScript>

What would you think about doing this instead: * Package both the minimized and the non minimized version in our WAR (it shouldn't add too much weight to our overall WAR size) * Have a directory structure like this:

resources/.../<module>/ |_ <non minified js file here> |_ min/<minified js files here>

* This would allow to put in our xwikivars.vm something like (pseudo code):

#if ("$!request.minify" == 'false') #set ($jsDir = '/') #else #set ($jsDir = 'min/' #end

* Then everywhere we reference JS files we use $jsDir. For example in attachmentsinline.vm:

$xwiki.jsfx.use('uicomponents/**widgets/${jsDir}upload.js', {'forceSkinAction': true, 'language': ${xcontext.language}})

This assumes that everywhere we reference js files is always in velocity, which is not true. I can think of at least one place, the dashboard macro ( https://github.com/xwiki/**xwiki-platform/blob/** e7c3855397bee00a5f1fe8b6fe9da6**08d4c4bb7f/xwiki-platform-** core/xwiki-platform-dashboard/**xwiki-platform-dashboard-** macro/src/main/java/org/xwiki/**rendering/internal/macro/** dashboard/DashboardMacro.java#**L232<https://github.com/xwiki/xwiki-platform/blob/e7c3855397bee00a5f1fe8b6fe9da608d4c4bb7f/xwiki-platform-core/xwiki-platform-dashboard/xwiki-platform-dashboard-macro/src/main/java/org/xwiki/rendering/internal/macro/dashboard/DashboardMacro.java#L232>). Now, I admit that one might not be the cleanest code ever, but I wonder what would stop anybody from wanting to include a resource from java or, say, groovy?

…

...

...

...

This would allow to remove the "debug" profile and make it much faster to debug XWiki issues, even in production systems.

WDYT?

Looks great, would be even better if the same option were passed automatically for JSX as well, which would ensure that all JS are not minified.

This is already the case and that's why I chose the "minify" request parameter name :)

See the following in AbstractSxAction.java:

if (BooleanUtils.toBoolean(**StringUtils.defaultIfEmpty( request.get(COMPRESS_SCRIPT_**REQUEST_PARAMETER), "true"))) { extensionContent = sxType.getCompressor().** compress(extensionContent); }

indeed, but this uses the parameters of the URL to the js (the jsx action URL). not the params of the page that demands the js. Which means that if you want to debug a page, you'd have to figure out all the scripts that the page is using, and make sure you add, one way or another, the minify=false parameter.

Also, it works if you load the jsx onDemand (when you'd be able to, say, request the jsx and add the {"minify": false} parameter), but it won't work for the automatically loaded jsx like "always on this wiki" or "always on this page". Also, adding this minify parameter to the call could be a pain, because you might not know which is the script that is loading the jsx, you have to go look for it, etc.

In the light of these 2 (3) things, it could maybe be nicer with some sort of a preference or so, although serving 2 different js for the same URL is not friendly with the browser cache. I need to think a bit more thorough to come up with an idea about how to make it better from this point of view.

Anca

...

Thanks -Vincent

______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>

______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs