Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

JSF "Loading" JavaScript -- Brief Overview

DZone's Guide to

JSF "Loading" JavaScript -- Brief Overview

· Java Zone
Free Resource

Learn how to troubleshoot and diagnose some of the most common performance issues in Java today. Brought to you in partnership with AppDynamics.

What remains unchanged is the way that JavaScript enter in the scene via the <script> tag as:

 <script type="text/javascript">
 //JavaScript Code
</script>

or, as:

 <script src="myScript.js"</script>

JSF is fully aware of the importance of this tag, and it renders it via <h:outputScript> tag. When the <script> tag should contain inline JavaScript code, the <h:outputScript> can be used, like this:

 <h:outputScript>
 //JavaScript Code
</h:outputScript>

If the JavaScript code is placed in an external, but local, file then <h:outputScript> is recommended to be used in accordance with JSF resource handlers. Starting with JSF 2.0, all the web resources, such as CSS, JavaScript, and images are loaded from a folder named resources, present under the root of your web application or from /META-INF/resources in JAR files (also see JSF 2.2 Resources and ResourceHandlers):

 <h:outputScript library="scripts" name="js/myScript.js"/>

A folder under resources folder is known as a library or theme, which is like a collection of client artifacts. We can also create a special folder matching the regex \d+(_\d+)* under the library folder for providing versioning. In this case, the default JSF resource handler will always retrieve the newest version to display. So, the library name is indicated via the library attribute, while the resource name via name attribute. Per example, if the myScript.js file is available in web_app_root/resources/scripts/js then it can be loaded like this:

<h:outputScript library="scripts" name="js/myScript.js"/>
Is important to know that, by default, <h:outputScript> can be used to load only local scripts. When your scripts should be loaded via absolute URLs, you can go back to <script> tag. Of course, you will lose the advantages provided by JSF, like versioning, but that's the price to pay ... unless you are ready to write a custom ResourceHandler. Or check the OmniFaces, CDNResourceHandler.

If you want to use local scripts, but not placed under resources folder, than you can set the following context parameter:

 <context-param>
 <param-name>javax.faces.WEBAPP_RESOURCES_DIRECTORY</param-name>
 <param-value>/new/path</param-value>
</context-param>

As a quick tip, you can use this to place your valuable resources under WEB-INF folder.

Commonly, the <script> tag appears in <head> or/and in <body>, and the indicated scripts are downloaded/loaded, processed/parsed and executed in the order they appear in the HTML page. The issue consist in the fact that these operations will block other actions on the page (e.g. HTML rendering) until they have done. Of course, this is the default behavior and it is almost naive, since loading and executing JavaScript codes relies on many techniques, like window.onload, $(document).ready() or HTML 5 async attribute. As a tip, it is a good idea to place scripts at the bottom of the <body>, since this will improve page load, because HTML loading is not "blocked" by scripts loading (e.g. Bootstrap "loves" this tip). Actually, notice the quotes around blocked word! They indicate the fact that actually none of the above solutions work 100%. In case that you need a JSF solution that really works - script is deferred after the entire page was fully loaded - check the OmniFaces DeferredScript component.

By default, JSF renders the <script> tag at the same point in the view where the tag is located, but we can alter his behavior via the target attribute. This can point out the head, the body or the form.


Understand the needs and benefits around implementing the right monitoring solution for a growing containerized market. Brought to you in partnership with AppDynamics.

Topics:

Published at DZone with permission of Anghel Leonard, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}