Jason Lee said the following on 2/13/07 12:06 PM PT:
> Interesting. If you're requesting a bunch of small files, you may be
> right. I think we drove this change/feature was the page size was
> getting pretty bloated on pages with lots of commandLinks, as the JS was
> repeated for each commandLink on the page.
I don't think so - the JS that we're talking about
gets written only once. From the 1.2_02 CommandLinkRenderer:
if (!hasScriptBeenRendered(context)) {
RenderKitUtils
.renderFormInitScript(
context.getResponseWriter(),
context);
setScriptAsRendered(context);
}
-- Adam
> With this change, it's
> downloaded once and used X times on a given page, and reused (I think ;)
> on other pages.
>
> -----
> Jason Lee, SCJP
> Programmer/Analyst
> http://www.iec-okc.com
>
>
>> -----Original Message-----
>> From: jacob_at_hookom.net [mailto:jacob_at_hookom.net]
>> Sent: Tuesday, February 13, 2007 1:48 PM
>> To: dev_at_javaserverfaces.dev.java.net
>> Subject: RE: Enable com.sun.faces.externalizeJavaScript by default?
>>
>> Does the JS ever change or is it static?
>>
>> What's the overhead of pushing another request through JSF
>> vs. sending the response down in one lot? We're tweaking our
>> own applications in an attempt to actually reduce the amount
>> of external requests for JS/CSS/etc. Looking at some .NET
>> apps, recieving 32k in a single request may prove more
>> performant than 4 or 5 requests over the internet for the
>> same amount of data (24k, 2k, 5k, 1k, 1k), each with a lag
>> time of 16ms>100ms even with the caching headers.
>>
>>
>>> So I'm curious what you all think about enabling
>>> com.sun.faces.externalizeJavaScript by default.
>>>
>>> If enabled:
>>>
>>> - The default commandLink renderer will render an external script
>>> reference for the commandLink JS
>>> instead of inlining in the page
>>> - A PL will be inserted into the lifecycle to intercept
>> the external
>>> JS request and serve the bytes
>>> (caching headers are set, so the browser shouldn't be
>> requesting
>>> said bytes repeatedly)
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>>> For additional commands, e-mail:
>> dev-help_at_javaserverfaces.dev.java.net
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>