Nabble - Tapestry - Dev

[jira] Created: (TAP5-255) Easy management of zones inside a loop

2008-10-07T10:24:44Z

Easy management of zones inside a loop
--------------------------------------

Key: TAP5-255
URL: https://issues.apache.org/jira/browse/TAP5-255
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Reporter: Stéphane Decleire

Enhancing the management of zones inside loops by removing the following zone limitation :
"Unlike many other situations, Tapestry relies on you to specify useful and unique ids to Zone components, then reference those ids inside ActionLink components.
Using Zone components inside any kind of loop may cause additional problems, as Tapestry will uniqueify the client id you specify (appending an index number)."

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jira] Updated: (TAPESTRY-2705) Exceeding file size limit throws uncatchable RuntimeException

2008-10-07T09:42:46Z

[ https://issues.apache.org/jira/browse/TAPESTRY-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joel Wiegman updated TAPESTRY-2705:
-----------------------------------

Fix Version/s: (was: 5.0.14)
Affects Version/s: 5.0.14

> Exceeding file size limit throws uncatchable RuntimeException
> -------------------------------------------------------------
>
> Key: TAPESTRY-2705
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2705
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-upload
> Affects Versions: 5.0.14
> Environment: Windows XP, Java 1.6, Sun Java Application Server 9.1
> Reporter: Joel Wiegman
>
> When including the following code in my app module to limit file size on an upload:
> public void contributeApplicationDefaults(MappedConfiguration<String, String> configuration) {
> configuration.add(UploadSymbols.FILESIZE_MAX, "1500000");
> }
> An following internal Tapestry exception gets thrown to the application server VM, which is of course uncatchable in application code.
> [#|2008-10-07T12:27:17.904-0400|SEVERE|Servlet.service() for servlet default threw exception
> java.lang.RuntimeException: Unable to decode multipart encoded request.
> at org.apache.tapestry5.upload.internal.services.MultipartDecoderImpl.parseRequest(MultipartDecoderImpl.java:116)
> at org.apache.tapestry5.upload.internal.services.MultipartDecoderImpl.decode(MultipartDecoderImpl.java:94)
> at $MultipartDecoder_11cd7ca67c8.decode($MultipartDecoder_11cd7ca67c8.java)
> at $MultipartDecoder_11cd7ca668e.decode($MultipartDecoder_11cd7ca668e.java)
> at org.apache.tapestry5.upload.internal.services.MultipartServletRequestFilter.service(MultipartServletRequestFilter.java:41)
> at $HttpServletRequestHandler_11cd7ca6691.service($HttpServletRequestHandler_11cd7ca6691.java)
> at org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62)
> at $HttpServletRequestFilter_11cd7ca668f.service($HttpServletRequestFilter_11cd7ca668f.java)
> at $HttpServletRequestHandler_11cd7ca6691.service($HttpServletRequestHandler_11cd7ca6691.java)
> at $HttpServletRequestHandler_11cd7ca668d.service($HttpServletRequestHandler_11cd7ca668d.java)
> at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:177)
> ......
> Caused by: org.apache.commons.fileupload.FileUploadBase$FileSizeLimitExceededException: The field fileToUpload exceeds its maximum permitted size of 1500000 characters.
> at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl$FileItemStreamImpl$1.raiseError(FileUploadBase.java:645)
> at org.apache.commons.fileupload.util.LimitedInputStream.checkLimit(LimitedInputStream.java:71)
> at org.apache.commons.fileupload.util.LimitedInputStream.read(LimitedInputStream.java:128)
> at java.io.FilterInputStream.read(FilterInputStream.java:90)
> at org.apache.commons.fileupload.util.Streams.copy(Streams.java:94)
> at org.apache.commons.fileupload.util.Streams.copy(Streams.java:64)
> at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:354)
> at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
> at org.apache.tapestry5.upload.internal.services.MultipartDecoderImpl.parseRequest(MultipartDecoderImpl.java:112)
> ... 61 more

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jira] Commented: (TAPESTRY-2698) Unable to decode multipart encoded request cuased by upload file

2008-10-07T09:42:46Z

[ https://issues.apache.org/jira/browse/TAPESTRY-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637541#action_12637541 ]

Joel Wiegman commented on TAPESTRY-2698:
----------------------------------------

This is a duplicate of TAPESTRY-2705, where a more accurate description can be found.

> Unable to decode multipart encoded request cuased by upload file
> ----------------------------------------------------------------
>
> Key: TAPESTRY-2698
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2698
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-upload
> Affects Versions: 5.0.15
> Environment: xp
> Reporter: srikanth
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I uploaded file with more than limit, it thrown exception as below, so their is any validator tag which support to prevent this exception ?
> java.lang.RuntimeException: Unable to decode multipart encoded request.
> at org.apache.tapestry5.upload.internal.services.MultipartDecoderImpl.parseRequest(MultipartDecoderImpl.java:116)
> at org.apache.tapestry5.upload.internal.services.MultipartDecoderImpl.decode(MultipartDecoderImpl.java:94)
> at $MultipartDecoder_11cb8950a1d.decode($MultipartDecoder_11cb8950a1d.java)
> at $MultipartDecoder_11cb89508ae.decode($MultipartDecoder_11cb89508ae.java)
> at org.apache.tapestry5.upload.internal.services.MultipartServletRequestFilter.service(MultipartServletRequestFilter.java:41)
> at $HttpServletRequestHandler_11cb89508b1.service($HttpServletRequestHandler_11cb89508b1.java)
> at org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62)
> at $HttpServletRequestFilter_11cb89508af.service($HttpServletRequestFilter_11cb89508af.java)
> at $HttpServletRequestHandler_11cb89508b1.service($HttpServletRequestHandler_11cb89508b1.java)
> at $HttpServletRequestHandler_11cb89508ad.service($HttpServletRequestHandler_11cb89508ad.java)
> at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:177)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:265)
> at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
> at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
> at com.btservices.storeportal.web.filter.WelcomeScreenGatewayFilter.doFilter(WelcomeScreenGatewayFilter.java:65)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
> at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
> at org.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:81)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
> at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:229)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
> at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
> at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:286)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
> at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:149)
> at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198)
> at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198)
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:288)
> at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
> at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
> at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
> at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
> at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
> at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
> at com.sun.enterprise.web.connector.grizzly.ssl.SSLReadTask.process(SSLReadTask.java:440)
> at com.sun.enterprise.web.connector.grizzly.ssl.SSLReadTask.doTask(SSLReadTask.java:228)
> at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
> at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
> Caused by: org.apache.commons.fileupload.FileUploadBase$FileSizeLimitExceededException: The field fileToUpload exceeds its maximum permitted size of 1500000 characters.
> at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl$FileItemStreamImpl$1.raiseError(FileUploadBase.java:645)
> at org.apache.commons.fileupload.util.LimitedInputStream.checkLimit(LimitedInputStream.java:71)
> at org.apache.commons.fileupload.util.LimitedInputStream.read(LimitedInputStream.java:128)
> at java.io.FilterInputStream.read(FilterInputStream.java:90)
> at org.apache.commons.fileupload.util.Streams.copy(Streams.java:94)
> at org.apache.commons.fileupload.util.Streams.copy(Streams.java:64)
> at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:354)
> at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
> at org.apache.tapestry5.upload.internal.services.MultipartDecoderImpl.parseRequest(MultipartDecoderImpl.java:112)
> ... 61 more

[jira] Created: (TAPESTRY-2705) Exceeding file size limit throws uncatchable RuntimeException

2008-10-07T09:34:44Z

Exceeding file size limit throws uncatchable RuntimeException
-------------------------------------------------------------

Key: TAPESTRY-2705
URL: https://issues.apache.org/jira/browse/TAPESTRY-2705
Project: Tapestry
Issue Type: Bug
Components: tapestry-upload
Environment: Windows XP, Java 1.6, Sun Java Application Server 9.1
Reporter: Joel Wiegman
Fix For: 5.0.14

When including the following code in my app module to limit file size on an upload:

public void contributeApplicationDefaults(MappedConfiguration<String, String> configuration) {
configuration.add(UploadSymbols.FILESIZE_MAX, "1500000");
}

An following internal Tapestry exception gets thrown to the application server VM, which is of course uncatchable in application code.

[#|2008-10-07T12:27:17.904-0400|SEVERE|Servlet.service() for servlet default threw exception
java.lang.RuntimeException: Unable to decode multipart encoded request.
at org.apache.tapestry5.upload.internal.services.MultipartDecoderImpl.parseRequest(MultipartDecoderImpl.java:116)
at org.apache.tapestry5.upload.internal.services.MultipartDecoderImpl.decode(MultipartDecoderImpl.java:94)
at $MultipartDecoder_11cd7ca67c8.decode($MultipartDecoder_11cd7ca67c8.java)
at $MultipartDecoder_11cd7ca668e.decode($MultipartDecoder_11cd7ca668e.java)
at org.apache.tapestry5.upload.internal.services.MultipartServletRequestFilter.service(MultipartServletRequestFilter.java:41)
at $HttpServletRequestHandler_11cd7ca6691.service($HttpServletRequestHandler_11cd7ca6691.java)
at org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62)
at $HttpServletRequestFilter_11cd7ca668f.service($HttpServletRequestFilter_11cd7ca668f.java)
at $HttpServletRequestHandler_11cd7ca6691.service($HttpServletRequestHandler_11cd7ca6691.java)
at $HttpServletRequestHandler_11cd7ca668d.service($HttpServletRequestHandler_11cd7ca668d.java)
at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:177)
......
Caused by: org.apache.commons.fileupload.FileUploadBase$FileSizeLimitExceededException: The field fileToUpload exceeds its maximum permitted size of 1500000 characters.
at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl$FileItemStreamImpl$1.raiseError(FileUploadBase.java:645)
at org.apache.commons.fileupload.util.LimitedInputStream.checkLimit(LimitedInputStream.java:71)
at org.apache.commons.fileupload.util.LimitedInputStream.read(LimitedInputStream.java:128)
at java.io.FilterInputStream.read(FilterInputStream.java:90)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:94)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:64)
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:354)
at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
at org.apache.tapestry5.upload.internal.services.MultipartDecoderImpl.parseRequest(MultipartDecoderImpl.java:112)
... 61 more

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jira] Commented: (TAPESTRY-2364) YSlow Recommendation: Write Scripts at bottom of page

2008-10-07T04:01:44Z

[ https://issues.apache.org/jira/browse/TAPESTRY-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637444#action_12637444 ]

Onno Scheffers commented on TAPESTRY-2364:
------------------------------------------

Hi Davor,

I'm glad you agree that we should be able to at least configure where the scripts are inserted.

The problem with the solution you give here is that
1) It is a hack to get something working that is actually quite common behavior.
2) It makes the page visible only after all the resources are loaded or loading and the scripts are all done running. This slows down page-loading instead of making it faster, defeating the whole purpose of adding the scripts to the end of the page.

I think we all agree now that it does make a difference if the scripts are included in the head-section or at the bottom of the page and it may cause problems for people.

If you look around at existing websites, nearly all of them have the scripts included in the head section. It is the most common approach and therefore the expected behavior for most people using the framework. Therefore I think the default behavior should be to include those file in the head-section.

But if it is at least configurable, I'm happy.

> YSlow Recommendation: Write Scripts at bottom of page
> -----------------------------------------------------
>
> Key: TAPESTRY-2364
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2364
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.0.12
>
> Attachments: sayHello.js, TestFast.html, TestSlow.html, TestSlow.html
>
>
> Tapestry is already doing a good job on this, by writing the dynamically generated <script> block at the bottom of the page, but the external scripts should also be down there.
> http://developer.yahoo.com/performance/rules.html#js_bottom

[jira] Updated: (TAP5-254) Translation for Spanish

2008-10-07T03:23:44Z

[ https://issues.apache.org/jira/browse/TAP5-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Ayala updated TAP5-254:
-----------------------------

Attachment: org.zip

> Translation for Spanish
> -----------------------
>
> Key: TAP5-254
> URL: https://issues.apache.org/jira/browse/TAP5-254
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.0.15
> Reporter: Pedro Ayala
> Attachments: org.zip
>
>
> Files for translation of components in Spanish

[jira] Created: (TAP5-254) Translation for Spanish

2008-10-07T03:15:44Z

Translation for Spanish
-----------------------

Key: TAP5-254
URL: https://issues.apache.org/jira/browse/TAP5-254
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.0.15
Reporter: Pedro Ayala

Files for translation of components in Spanish

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jira] Commented: (TAPESTRY-2364) YSlow Recommendation: Write Scripts at bottom of page

2008-10-07T03:09:44Z

[ https://issues.apache.org/jira/browse/TAPESTRY-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637433#action_12637433 ]

Davor Hrg commented on TAPESTRY-2364:
-------------------------------------

ok,

I agree that this should be considered as optional,
but the default should be scripts at bottom.

and another solution with considering the users without js

add this script as first line after body:
<script>document.body.style.visibility = "hidden";</script>

and this script at the bottom (after doing your DOM magic)
<script>document.body.style.visibility = "visible";</script>

this will have no effect for users with disabled js
it will make content hidden until it is modified by the script
it will work no matter if scripts are in HEAD or at bottom
this approach can even be used in combination with classic onload
(before this last snippet of course)

[jira] Created: (TAP5-253) Default validation messages only overridable individually

2008-10-07T02:57:45Z

Default validation messages only overridable individually
---------------------------------------------------------

Key: TAP5-253
URL: https://issues.apache.org/jira/browse/TAP5-253
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.0.15
Reporter: Andy Blower
Priority: Minor

I'm trying to set up validation for our forms and I need to customise the default validation messages. Unfortunately there doesn't seem to be a way to do this as contributing to ValidationMessagesSource just adds new messages for new validators. I need to change the default messages to what we need.

I know that we can override the message for each field name in the message catalogs, but this is undesirable (& expensive with extra translations needed) because they'll all be the same. The only solution I've found is to override this with a properties file in the tapestry5.internal package but this doesn't work in every environment so it's not really a good solution.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jira] Issue Comment Edited: (TAPESTRY-2364) YSlow Recommendation: Write Scripts at bottom of page

2008-10-07T01:37:44Z

[ https://issues.apache.org/jira/browse/TAPESTRY-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637417#action_12637417 ]

onno edited comment on TAPESTRY-2364 at 10/7/08 1:36 AM:
-------------------------------------------------------------------

@Davor Hrg

Your solution wouldn't work because if you generate invisible content on the server and then make it visible on the client using Javascript, then the application won't work for people that have Javascript disabled. For me it is an absolute requirement to have pages work without Javascript.

In my case I'm showing a couple of questions on the page. For each question it is possible to add a note and to upload a file. Since adding a note or attaching a file is the exception rather than the rule and since the textarea and upload-field take up precious space and may even confuse users, we hide those areas using Javascript and add a coule of icons for expanding the areas when you need them.
This improves the user-experience for people that have Javascript enabled, but still allows people without Javascript to see the areas and use their functionality.

This is really a very common approach that is being used in several companies I've worked for, especially for government work where it is essential users can access the web applications without Javascript.

was (Author: onno):
@Davor Hrg

Your solution wouldn't work because if you generate invisible content on the server and then make it visible on the client using Javascript, then the application won't work for people that have Javascript disabled. For me it is an absolute requirement to have pages work without Javascript.

In my case I'm showing a couple of questions on the page. For each question it is possible to add a note and to upload a file. Since adding a note or attaching a file is the exception rather than the rule and since the textarea and upload-field take up precious space and may even confuse users, we hide those areas using Javascript and add a coule of icons for collapsing the areas.
This improves the user-experience for people that have Javascript enabled, but still allows people without Javascript to see the areas and use their functionality.

This is really a very common approach that is being used in several companies I've worked for, especially for government work where it is essential users can access the web applications without Javascript.

[jira] Commented: (TAPESTRY-2364) YSlow Recommendation: Write Scripts at bottom of page

2008-10-07T01:35:44Z

[jira] Updated: (TAPESTRY-2364) YSlow Recommendation: Write Scripts at bottom of page

2008-10-07T00:14:44Z

[ https://issues.apache.org/jira/browse/TAPESTRY-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Davor Hrg updated TAPESTRY-2364:
--------------------------------

Attachment: TestSlow.html

ok,
disclaimer: I'm talking from my experience, I may not be right after all :)

I understand you wanting to do things before onload,
and right after dom is loaded.

This however does not mean that scripts can not be on the bottom.

If you want to change the whole document before rendering
you definitely must wait for the whole html to be read by browser,
and if the page is big enough (a huge table 50x100 with loads of markup)
the rendering will start even before the whole document is read.

if you have an example of the page where it is a clear difference
when changing content before render and simply onload
I'm convinced I can make it work with scripts on the bottom.

.....
you can definitely hide the content before rendering and without a line of js
the example is untested, but you can understand what I mean....

<div id="hideDiv" style="display:none">
...content.....
</div>
<script .... js libs...>
<script>
//transform dom (all dom is loaded if the script is at bottom)

var div = document.getElementById("hideDiv");

//show div
//div.style.display = "block";

//or remove div from body and move all it's children to body
console.log(div.firstChild);
while(div.firstChild){
document.body.appendChild(div.firstChild);//it will be removed from div automatically
}
document.body.removeChild(div);

</script>

adding scripts to bottom or top definitely makes a difference,
having it as an option brings more complexity to users that are
more server side centric.

If you want to manipulate dom you can do it on the server side as well
(not as many options there though)

here is the TestSlow that does not show content before the alert
(the alert will be shown later because the images will start loading before
since they are before scripts in the source)

[jira] Commented: (TAPESTRY-2364) YSlow Recommendation: Write Scripts at bottom of page

2008-10-06T17:53:44Z

[ https://issues.apache.org/jira/browse/TAPESTRY-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637332#action_12637332 ]

Onno Scheffers commented on TAPESTRY-2364:
------------------------------------------

@Filip

Hi Filip,

I know that dom:loaded will be called before images etc. are loaded, but that is just my point: The js-files that attach to the event may not be loaded before the images. As a matter of fact: The dom:loaded event should have passed by the time the scripts are loaded (since the browser doesn't wait for them, but the dom is ready).

Prototype seems to be smart and fires the event, even if it the listener is attached after the event actually occured, but I've had this problem with JQuery a while back where Javascripts couldn't act on the domloaded event anymore because they were loaded after the dom was ready.

> YSlow Recommendation: Write Scripts at bottom of page
> -----------------------------------------------------
>
> Key: TAPESTRY-2364
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2364
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.0.12
>
> Attachments: sayHello.js, TestFast.html, TestSlow.html
>
>
> Tapestry is already doing a good job on this, by writing the dynamically generated <script> block at the bottom of the page, but the external scripts should also be down there.
> http://developer.yahoo.com/performance/rules.html#js_bottom

[jira] Updated: (TAPESTRY-2364) YSlow Recommendation: Write Scripts at bottom of page

2008-10-06T17:41:44Z

[ https://issues.apache.org/jira/browse/TAPESTRY-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Onno Scheffers updated TAPESTRY-2364:
-------------------------------------

Attachment: TestFast.html
TestSlow.html
sayHello.js

To be honest, I didn't know it worked like this either and it seems to differ per browser. On Firefox 3 (OSX) the effect is pretty obvious, even if you include just one js-file at the end of the file. On other browsers the problems start to show up only when more js-files are added to the end of the file (like Tapestry does).

So some browsers are smarter and do immediately include cached resources, but even they have to include the javascript files one after another, which still takes many seconds with big libraries like Prototype and scipt.aculo.us.

Here's a test-case, using big images and external resources to make things more apparent, tested in Firefox 3, Opera and Safari (OSX, Mac Pro 8-core). Opera is the fastest, Firefox seems to be slowest.

- sayHello.js is a Javacript file that simply shows an alert-box when it gets executed. It will be included in the two example pages.

- TestSlow.html is how Tapestry does it now. I added a couple of large images on the page and included several external js-files to the end of the page. It is most visible on first page-load (or after the cache is cleared). The Javascript isn't executed until most of the resources are loaded or have started loading.

- TestFast.html includes a couple of js-files in the HEAD section. The page stays white a little longer, but the alert-box is shown immediately and before the page renders.

> YSlow Recommendation: Write Scripts at bottom of page
> -----------------------------------------------------
>
> Key: TAPESTRY-2364
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2364
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.0.12
>
> Attachments: sayHello.js, TestFast.html, TestSlow.html
>
>
> Tapestry is already doing a good job on this, by writing the dynamically generated <script> block at the bottom of the page, but the external scripts should also be down there.
> http://developer.yahoo.com/performance/rules.html#js_bottom

[jira] Commented: (TAPESTRY-2364) YSlow Recommendation: Write Scripts at bottom of page

2008-10-06T16:32:44Z

[ https://issues.apache.org/jira/browse/TAPESTRY-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637301#action_12637301 ]

Filip S. Adamsen commented on TAPESTRY-2364:
--------------------------------------------

Actually, dom:loaded will be called before images etc. are loaded, so it's rarely a problem.

> YSlow Recommendation: Write Scripts at bottom of page
> -----------------------------------------------------
>
> Key: TAPESTRY-2364
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2364
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.0.12
>
>
> Tapestry is already doing a good job on this, by writing the dynamically generated <script> block at the bottom of the page, but the external scripts should also be down there.
> http://developer.yahoo.com/performance/rules.html#js_bottom

[jira] Created: (TAPESTRY-2704) Documentation for BeanEditForm attribute to remove columns is incorrect

2008-10-06T16:28:44Z

Documentation for BeanEditForm attribute to remove columns is incorrect
-----------------------------------------------------------------------

Key: TAPESTRY-2704
URL: https://issues.apache.org/jira/browse/TAPESTRY-2704
Project: Tapestry
Issue Type: Bug
Components: Web
Reporter: Al Wold

At http://tapestry.apache.org/tapestry5/guide/beaneditform.html, it says this:

The BeanEditForm component has two parameters for this purpose:

* remove: A comma separated list of property names to remove from the model.

The parameter is actually called "exclude".

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jira] Commented: (TAPESTRY-2364) YSlow Recommendation: Write Scripts at bottom of page

2008-10-06T15:54:44Z

[ https://issues.apache.org/jira/browse/TAPESTRY-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637290#action_12637290 ]

Martin Strand commented on TAPESTRY-2364:
-----------------------------------------

> The browser only loads two resources at once.
I honestly had no idea that the limit would affect cached resources too, but if that really is how it works you certainly bring up a valid point for cases where the DOM must be manipulated with javascript before being rendered.

> YSlow Recommendation: Write Scripts at bottom of page
> -----------------------------------------------------
>
> Key: TAPESTRY-2364
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2364
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.0.12
>
>
> Tapestry is already doing a good job on this, by writing the dynamically generated <script> block at the bottom of the page, but the external scripts should also be down there.
> http://developer.yahoo.com/performance/rules.html#js_bottom

[jira] Commented: (TAPESTRY-2364) YSlow Recommendation: Write Scripts at bottom of page

2008-10-06T14:51:44Z

[ https://issues.apache.org/jira/browse/TAPESTRY-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637263#action_12637263 ]

Onno Scheffers commented on TAPESTRY-2364:
------------------------------------------

> You say the overhead is minimal since the script is cached, but that also applies to your own use case.

Actually, it doesn't.
The browser only loads two resources at once. This means the js-files, which are the last resources on the page, will not be resolved until all other resources are loaded (e.g. all images and all other scripts). So even if they are cached, the slowdown is considerable because I have to wait for _all_ other resources to be loaded before the script gets executed.

Meanwhile the page has been rendered and is visible to the user. The user may even start clicking on items that shouldn't even have been visible to him or her, depending on how big the images on the page are or how slow the connection is.

> YSlow Recommendation: Write Scripts at bottom of page
> -----------------------------------------------------
>
> Key: TAPESTRY-2364
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2364
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.0.12
>
>
> Tapestry is already doing a good job on this, by writing the dynamically generated <script> block at the bottom of the page, but the external scripts should also be down there.
> http://developer.yahoo.com/performance/rules.html#js_bottom

Re: [jira] Commented: (TAPESTRY-2364) YSlow Recommendation: Write Scripts at bottom of page

2008-10-06T14:17:43Z

ok,disclaimer: I'm talking from my experience, I may not be right after all
:)

I understand you wanting to do things before onload,
and right after dom is loaded.

This however does not mean that scripts can not be on the bottom.

If you want to change the whole document before rendering
you definitely must wait for the whole html to be read by browser,
and if the page is big enough (a huge table 50x100 with loads of markup)
the rendering will start even before the whole document is read.

if you have an example of the page where it is a clear difference
when changing content before render and simply onload
I'm convinced I can make it work with scripts on the bottom.

.....
you can definitely hide the content before rendering and without a line of
js
the example is untested, but you can understand what I mean....

<div content ... style="display:none">
...content.....
</div>
<script .... js libs...>
<script>
//transform dom (all dom is loaded if the script is at bottom)

//show div
var div = document.body.firstChild;
div.style.display = "block";

//or remove div from body and move all it's children to body
document.body.removeChild(div);
while(div.firstChild){
document.body.appendChild(div.firstChild);//it will be removed from div
automatically
}
</script>

On Mon, Oct 6, 2008 at 9:45 PM, Onno Scheffers (JIRA) <
dev@...> wrote:

>
> [
> https://issues.apache.org/jira/browse/TAPESTRY-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637199#action_12637199]
>
> Onno Scheffers commented on TAPESTRY-2364:
> ------------------------------------------
>
> > this is simply untrue.
> > QUOTE: "Otherwise it is impossible to execute Javascript before the page
> renders..."
>
> You cut off the part of the sentence that really mattered.
>
> An onload-event is triggered when ALL resources are loaded (including
> images and script-files). The page starts rendering as soon as possible
> (even before the resources are loaded). Have you never seen the text popup
> in a browser before the images were loaded? That's the difference between
> dom:loaded and the onload event.
>
> This means rendering starts BEFORE the Prototype libraries are even loaded,
> which means the custom Javascript will be executed even later, since that
> relies on the Prototype libraries being loaded. It really is true. I can
> even prove it with example-code if you don't believe me.
>
>
> > A listener to onload can be added no matter where script tags are. onload
> will not be called until all page resources are loaded.
>
> Indeed, but the page will be rendered before the resources are loaded.. you
> can see the text appear in the browser before the images are loaded quite
> clearly.
>
>
> > you can always make content hidden, and show it after parsing it.
>
> But not before _rendering_ it!
>
> > YSlow Recommendation: Write Scripts at bottom of page
> > -----------------------------------------------------
> >
> > Key: TAPESTRY-2364
> > URL: https://issues.apache.org/jira/browse/TAPESTRY-2364
> > Project: Tapestry
> > Issue Type: Improvement
> > Components: tapestry-core
> > Reporter: Howard M. Lewis Ship
> > Assignee: Howard M. Lewis Ship
> > Priority: Minor
> > Fix For: 5.0.12
> >
> >
> > Tapestry is already doing a good job on this, by writing the dynamically
> generated <script> block at the bottom of the page, but the external scripts
> should also be down there.
> > http://developer.yahoo.com/performance/rules.html#js_bottom
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[jira] Commented: (TAPESTRY-2364) YSlow Recommendation: Write Scripts at bottom of page

2008-10-06T14:11:44Z

[ https://issues.apache.org/jira/browse/TAPESTRY-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637225#action_12637225 ]

Martin Strand commented on TAPESTRY-2364:
-----------------------------------------

I understand your concern Onno, I just believe the more common case is to have it the other way around - wanting the page to render as quickly as possible on the first visit.

You say the overhead is minimal since the script is cached, but that also applies to your own use case.
Your problem occurs when the page is fully rendered and the client waits for those scripts at the bottom to load before you get to manipulate the DOM. That would not be an issue once the scripts are cached.

> YSlow Recommendation: Write Scripts at bottom of page
> -----------------------------------------------------
>
> Key: TAPESTRY-2364
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2364
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.0.12
>
>
> Tapestry is already doing a good job on this, by writing the dynamically generated <script> block at the bottom of the page, but the external scripts should also be down there.
> http://developer.yahoo.com/performance/rules.html#js_bottom

[jira] Commented: (TAPESTRY-2364) YSlow Recommendation: Write Scripts at bottom of page

2008-10-06T12:45:44Z

[ https://issues.apache.org/jira/browse/TAPESTRY-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637199#action_12637199 ]

Onno Scheffers commented on TAPESTRY-2364:
------------------------------------------

> this is simply untrue.
> QUOTE: "Otherwise it is impossible to execute Javascript before the page renders..."

You cut off the part of the sentence that really mattered.

An onload-event is triggered when ALL resources are loaded (including images and script-files). The page starts rendering as soon as possible (even before the resources are loaded). Have you never seen the text popup in a browser before the images were loaded? That's the difference between dom:loaded and the onload event.

This means rendering starts BEFORE the Prototype libraries are even loaded, which means the custom Javascript will be executed even later, since that relies on the Prototype libraries being loaded. It really is true. I can even prove it with example-code if you don't believe me.

> A listener to onload can be added no matter where script tags are. onload will not be called until all page resources are loaded.

Indeed, but the page will be rendered before the resources are loaded.. you can see the text appear in the browser before the images are loaded quite clearly.

> you can always make content hidden, and show it after parsing it.

But not before _rendering_ it!

> YSlow Recommendation: Write Scripts at bottom of page
> -----------------------------------------------------
>
> Key: TAPESTRY-2364
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2364
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.0.12
>
>
> Tapestry is already doing a good job on this, by writing the dynamically generated <script> block at the bottom of the page, but the external scripts should also be down there.
> http://developer.yahoo.com/performance/rules.html#js_bottom

[jira] Commented: (TAPESTRY-2364) YSlow Recommendation: Write Scripts at bottom of page

2008-10-06T12:37:44Z

[ https://issues.apache.org/jira/browse/TAPESTRY-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637193#action_12637193 ]

Onno Scheffers commented on TAPESTRY-2364:
------------------------------------------

> But the DOM isn't loaded any faster just because you put the script tag further up in your document, you still need to load the entire page first.

Well, the DOM is loaded faster if you put the scripts tags outside of the HEAD tag, since the browsers waits until everything in the HEAD is loaded, while it doesn't wait for resources outside of the head. So it does give a speedup if you place the scripts at the bottom of the file.

> If I understand your concern, you want your user to see a blank page while waiting for scripts in <head> to load, rather than your user seeing the full page while waiting for scripts at the bottom of the page to load?

That's right. Usually css-files are placed in the HEAD to make sure they are loaded before rendering. But often Javascript is used for toggling styles or hiding things as well, so it should be possible to execute that Javascript before the page is shown to the user.

> I believe that's the opposite of what most others want so it should probably not be the default behaviour.

I'm not sure I agree. If you look at any of the example pages of any of the Javascript-frameworks. They pretty much all use a dom:loaded event to alter the HTML before the page gets rendered and it's not just Prototype. It's also one of the first items the JQuery tutorial teaches you for example:
http://docs.jquery.com/Tutorials:Getting_Started_with_jQuery#Hello_jQuery

> I believe putting scripts at the bottom so that the page renders faster is likely what most people want. If someone actually wants the page to render slower or needs to execute a script before the dom is loaded, there could be a simple workaround or a configuration option for putting scripts at the top of the page.

It is really quite common to have the Javascript in the HEAD section and currently it is not possible in Tapestry. It should at least be configurable. I still think it should be default behavior as well since you are forcing people to change the configuration to do the most-common thing, while usually you'll start configuring things only if you want to tweak the performance.

Also, the overhead of placing those files in the HEAD is minimal, since the browser caches the js-files.

> YSlow Recommendation: Write Scripts at bottom of page
> -----------------------------------------------------
>
> Key: TAPESTRY-2364
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2364
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.0.12
>
>
> Tapestry is already doing a good job on this, by writing the dynamically generated <script> block at the bottom of the page, but the external scripts should also be down there.
> http://developer.yahoo.com/performance/rules.html#js_bottom

[jira] Commented: (TAPESTRY-2364) YSlow Recommendation: Write Scripts at bottom of page

2008-10-06T12:19:44Z

[ https://issues.apache.org/jira/browse/TAPESTRY-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637184#action_12637184 ]

Davor Hrg commented on TAPESTRY-2364:
-------------------------------------

this is simply untrue.
QUOTE: "Otherwise it is impossible to execute Javascript before the page renders..."

A listener to onload can be added no matter where script tags are.
onload will not be called until all page resources are loaded.

if you use tapestry to add script to the page, the script will be called inside an onload
handler (after all scripts are loaded).

you can always make content hidden, and show it after parsing it.

> YSlow Recommendation: Write Scripts at bottom of page
> -----------------------------------------------------
>
> Key: TAPESTRY-2364
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2364
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.0.12
>
>
> Tapestry is already doing a good job on this, by writing the dynamically generated <script> block at the bottom of the page, but the external scripts should also be down there.
> http://developer.yahoo.com/performance/rules.html#js_bottom

[jira] Commented: (TAPESTRY-2364) YSlow Recommendation: Write Scripts at bottom of page

2008-10-06T11:39:44Z

[ https://issues.apache.org/jira/browse/TAPESTRY-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637171#action_12637171 ]

Martin Strand commented on TAPESTRY-2364:
-----------------------------------------

But the DOM isn't loaded any faster just because you put the script tag further up in your document, you still need to load the entire page first.

If I understand your concern, you want your user to see a blank page while waiting for scripts in <head> to load, rather than your user seeing the full page while waiting for scripts at the bottom of the page to load? I believe that's the opposite of what most others want so it should probably not be the default behaviour.

I believe putting scripts at the bottom so that the page renders faster is likely what most people want. If someone actually wants the page to render slower or needs to execute a script before the dom is loaded, there could be a simple workaround or a configuration option for putting scripts at the top of the page.

> YSlow Recommendation: Write Scripts at bottom of page
> -----------------------------------------------------
>
> Key: TAPESTRY-2364
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2364
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.0.12
>
>
> Tapestry is already doing a good job on this, by writing the dynamically generated <script> block at the bottom of the page, but the external scripts should also be down there.
> http://developer.yahoo.com/performance/rules.html#js_bottom

[jira] Commented: (TAPESTRY-2364) YSlow Recommendation: Write Scripts at bottom of page

2008-10-06T10:13:44Z

[ https://issues.apache.org/jira/browse/TAPESTRY-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637142#action_12637142 ]

Onno Scheffers commented on TAPESTRY-2364:
------------------------------------------

I think the external libraries, especially the Prototype libs should always be included in the head section. Otherwise it is impossible to execute Javascript before the page renders, assuming developers are allowed to use Prototype in their own scripts as well.

Prototype included the dom:loaded event for a reason: This feature is used a lot!
If you want to create webpages that work without Javascript, you typically render plain HTML and then modify the HTML with Javascript before rendering, so you can give people with Javascript a better user-experience.

When all scripts are added to the end of the page, like it is now, the page is rendered before all resources are loaded and the user sees things (s)he wasn't supposed to see (like areas collapsing etc.).

I've seen quite a few complaints about it on the mailinglist already and some people are including the libraries twice into their pages now to work around problems. If there's hardly a difference in YSlow, then why make things more complex for developers than they need to be?

> YSlow Recommendation: Write Scripts at bottom of page
> -----------------------------------------------------
>
> Key: TAPESTRY-2364
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2364
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.0.12
>
>
> Tapestry is already doing a good job on this, by writing the dynamically generated <script> block at the bottom of the page, but the external scripts should also be down there.
> http://developer.yahoo.com/performance/rules.html#js_bottom