Ajax
Beans
Callbacks
Components
Events
Exceptions
Faces
Facelets
JSON
Hacks
State 
JNDI
Platform
Utils
Messages
MapWrapper
Reflection
Renderers
ResourcePaths
XML
Servlets
Arrays
Converters
Dates
Numbers
Objects
Strings
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="default" 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/default/js
then it can be loaded like this:
<h:outputScript library="default"
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.
<h:inputText/> 
ZEEF JSF Beginner's Guide 
JSF 2 Tutorials at www.mkyong.com 
JavaServer Faces (JSF) Tutorial 
Postări
Niciun comentariu :
Trimiteți un comentariu