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.
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
