25+ Reasons to use OmniFaces in JSF applications

25+ Reasons to use OmniFaces in JSF applications
Anghel Leonard

What we will cover ? (I)
• Enable restorable view
• Loading CDN resources
• Loading images as stream/byte array
• OmniFaces converters
• OmniFaces validators
• OmniFaces server-side Cache
• Defer JavaScript loading
• Preserve view/request parameters on post-back
• Execute JSF AJAX request via JavaScript method call
• OmniFaces tree hierarchy
• OmniFaces stateless ViewParam
• Full AJAX exception handler
• Highlight invalid inputs
• OmniFaces boosted messages

What we will cover ? (II)
• Eagerly instantiate scoped beans
• OmniFaces PartialViewContext
• OmniFaces events for Invoke Application
• Auto-generated JSF component IDs
• Extensionless URLs
• Import constants
• Import functions
• Combined resource handler
• Unmapped resource handler
• Injecting cookies and context params
• OmniFaces filters
• OmniFaces ViewScope
• OmniFaces utilities methods
• OmniFaces utilities functions

What is OmniFaces ?
• Well, if this is the first time when you hear about OmniFaces then you have to know
that OmniFaces is a utility library for JSF and a comprehensive compendium of
programming techniques, design patterns and recipes for JSF developers.
• Read before: Introduction to OmniFaces by Anghel Leonard

Enable restorable view
Your application works like a charm, but ViewExpiredException spoil all the
satisfaction ?
OmniFaces fix this problem via a custom tag handler that instructs the view
handler to recreate the entire view whenever the view has been expired. So,
check how easy is to get rid of this exception using
<o:enableRestorableView>.

Loading CDN resources
If you want to use <h:outputScript> and <h:outputStylesheet> to
load external resources from CDNs (e.g. Google Hosted Libraries), then
you know that this is not possible in default JSF ?
OmniFaces comes with the solution via a custom resource handler, named
CDNResourceHandler. This will simply allows you to load resources from
CDNs via <h:outputScript> and <h:outputStylesheet>.

Loading images as stream/byte array
You need to render images that comes as InputStream or byte[] ?
You want to render them as data URI or load SVG files?
OmniFaces provides the <o:graphicImage>, which is an extension of the
<h:graphicImage> dedicated to render JSF resource as data URI,
InputStream/byte[] property as resource, InputStream
/byte[] property as data URI, etc. Just check the OmniFaces Showcase.

OmniFaces converters
JSF custom converters are time consuming, they are called at every request
regardless of whether the submitted value has changed or not, or they need to
do the job based on possibly expensive service/DAO operations, etc.
Just if you read the names of converters provides out of the box by OmniFaces,
you will take into account to check them at your first need to write a custom
converter:
GenericEnumConverter
ListConverter
ListIndexConverter
SelectItemsConverter
SelectItemsIndexConverter
ValueChangeConverter
Read further: OmniFaces Converters by Constantin Alin

OmniFaces validators
Components validation is interdependent ? Need special custom validators to:
- validate if ONLY ONE of the given UIInput components have been filled out ?
- validate if ALL of the given UIInput components have been filled out ?
- validate if ALL of the given UIInput components have the same value ?
- validate if ONLY ONE of the given UIInput components has been filled out or
that NONE of the given UIInput components have been filled out ?
…
If you answered yes, or you think of some other case, then OmniFaces has
a set of 14 special custom validators.
Read further: OmniFaces Validators by Anghel Leonard

OmniFaces server-side Cache
Your page source code contains a lot of markup ? Well, the Render Response
phase is the most time consuming JSF phase, especially in cases when the
rendered markup is consistent.
You can speed up this process with a snap of a finger via the OmniFaces
Cache component. Caching markup will boost the Render Response phase
(check some tests here). The examples provided by OmniFaces Showcase are
very clear and well explained.
Read further: Test OmniFaces Cache for Render Response Phase by Anghel Leonard

Defer JavaScript loading
I know a trendy topic: deferred scripts. I'm pretty sure that you heard about
placing the scripts at the end of </body>, use defer="true“ or async=
"true", but I'm not so sure that you know that these approaches are not really
working as expected.
The OmniFaces, <o:deferredScript> defers the loading of the given script
resource to the window load event (the given script resource is only loaded
when the window is really finished with loading).

Preserve view/request
parameters on post-back
As you know, when we submit JSF forms we simply cannot preserve
view or request parameters in the request URL.
Well, OmniFaces fixes this issue via Form (<o:form>) component, which
extends the standard <h:form> and provides a way to keep view or request
parameters in the request URL after a post-back and offers in combination with
the <o:ignoreValidationFailed> tag on an UICommand component the
possibility to ignore validation failures so that the invoke action phase will be
executed anyway.

Execute JSF AJAX request via
JavaScript method call
As an end-user you may want to execute a JSF AJAX request via a
JavaScript function call. Well, OmniFaces provides the CommandScript
component exactly for this purpose.
The <o:commandScript> is a component based on the standard
<h:commandXxx> which generates a JavaScript function in the global
JavaScript scope which allows the end-user to execute a JSF AJAX request
by just a function call functionName() in the JavaScript context.

OmniFaces tree hierarchy
OmniFaces comes with Tree component.
The <o:tree> allows the developers to have full control over the markup
of a tree hierarchy by declaring the appropriate JSF components or HTML
elements in the markup. The <o:tree> does namely not render any
HTML markup by itself.
Beside the OmniFaces Showcase, you can check some examples here:
Use OmniFaces Tree to render JSON
Expose a path as an OmniFaces tree (<o:tree>)
Building dynamic responsive multi-level menus with plain HTML and OmniFaces

OmniFaces stateless ViewParam
The JSF built-in <f:viewParam> is a stateful artifact. This causes major
issues as Arjan Tijms points on his blog. OmniFaces, comes with a
stateless ViewParam component.
The <o:viewParam> is a component that extends the standard
<f:viewParam> and provides a stateless mode of operation and fixes
the issue wherein null model values are converted to empty string
parameters in query string (e.g. when includeViewParams=true) and
the (bean) validation never being triggered when the parameter is
completely absent in query string, causing e.g. @NotNull to fail.

Full AJAX exception handler
By default, most of AJAX exceptions are invisible to the client. They are
returned to the client, but unfortunately JSF AJAX clients aren't prepared to
deal with arbitrary error messages, so they simply ignore them. But a custom
exception handler is specially created for this task by OmniFaces.
The handler is named FullAjaxExceptionHandler, and the factory is
named FullAjaxExceptionHandlerFactory. This will give to your
AJAX based applications a real boost, because your end users would know
if their actions was successfully performed or not.

Highlight invalid inputs
Beside validation messages, you simply want to highlight the invalid inputs of
a form via some CSS ?
The OmniFaces, <o:highlight> is a helper component which highlights
all invalid UIInput components and the associated labels by adding an
error style class to them. Additionally, it by default focuses the first invalid
UIInput component.

OmniFaces boosted messages
Working with <h:message> and <h:messages> has several important
limitations.
OmniFaces, comes with <o:messages>, which allows us to
specify multiple client IDs space separated in the for attribute, show a single
custom message whenever the component has received any faces message,
HTML escaping and messages iteration markup control.

Eagerly instantiate scoped beans
CDI managed beans doesn’t have the ability to eagerly instantiate application
scoped beans.
OmniFaces fills this void and even goes one step further by
introducing the @Eager annotation that can be applied to @RequestScoped,
@ViewScoped, @SessionScoped and @ApplicationScoped beans.
This causes these beans to be instantiated automatically at the start of each
such scope instead of on demand when a bean is first referenced.

OmniFaces PartialViewContext
Do you need to:
• Execute callback scripts by
PartialResponseWriterstartEval() ?
• Add arguments to AJAX response ?
• Prevents errors about malformed XML caused by tags which
Mojarra and MyFaces has left open after an exception in rendering
of an already committed AJAX response ?
• Fix the no-feedback problem when a ViewExpiredException
occurs during an AJAX request on a page which is restricted by
web.xml <security-constraint> ?
Then you need the OmniFaces, OmniPartialViewContext.

OmniFaces events for Invoke Application
JSF comes with a considerable number of events, but none of them is related
to Invoke Application phase.
OmniFaces fills this void with the InvokeActionEventListener which add
support for the new <f:event> types: preInvokeAction and
postInvokeAction. Those events are published during the beforephase and
afterphase of INVOKE_APPLICATION respectively. This actually offers a better
hook on invoking actions after the <f:viewParam> values been set than the
preRenderView event.
Starting with OmniFaces 2.2, any component will support these two events.

Auto-generated JSF component IDs
As you know, JSF will provide auto-generated IDs for each component
that doesn’t have an explicit ID.
OmniFaces has an view handler, NoAutoGeneratedIdViewHandler
which inspects the rendered output and signal via an
llegalStateException whenever an automatically generated JSF
component ID (j_id...) is encountered in the rendered output.

Extensionless URLs
Do you find the presence of the extension (e.g. .xhtml) inappropriate in
the URL ?
Well, OmniFaces comes with FacesViews, which is a
mechanism to use SEO-friendly extensionless URLs in a JSF
application without the need to enlist individual Facelet source files in
some configuration file.
Instead, Facelets source files can be put into either the special /WEB-
INF/faces-views directory, from where they will be automatically scanned
(no configuration whatsoever required) or an explicit directory can be
configured to be scanned. The web app root is supported as well.

Import constants
By default, constant field values cannot be use in JSF pages.
Well, OmniFaces provides the ImportConstants tag handler that allows
the developer to have a mapping of all constant field values of the given
fully qualified name of a type in the request scope (e.g. declared as,
public static final).

Import functions
By default, functions that are not registered in .taglib.xml file cannot be
use in JSF pages.
Well, OmniFaces comes with the ImportFunctions tag handler which allows
developers to have access to all functions of the given fully qualified name of a
type in the Facelet scope using the usual EL functions syntax without the need
to register them in .taglib.xml file. The functions are those public
static methods with a non-void return type.

Combined resource handler
As you know, for each resource (CSS and JS) we have a separate request.
OmniFaces seriously improve the page loading speed via the
CombinedResourceHandler resource handler.
This will remove all separate script and stylesheet resources which have the
target Attributeset to head from the UIViewRoot and create a combined
one for all scripts and another combined one for all stylesheets.

Unmapped resource handler
When we need to reference relative URLs to images in CSS files we can use
the #{resource} EL expression in images paths. This issue is solved by
OmniFaces via the UnmappedResourceHandler.
This implementation allows the developer to map JSF resources on an URL
pattern of /javax.faces.resource/* without the need for an additional
FacesServlet prefix or suffix URL pattern in the default produced resource
URLs.

Injecting cookies and context params
Need quick access to information stored in cookies and context
parameters ? Preferably via CDI injection ?
Well, OmniFaces provides @Cookie annotation for injecting cookie
data and @ContextParam annotation for injecting context parameters
(the later is available starting with OmniFaces 2.2).

OmniFaces filters
OmniFaces comes with several filters, as follows:
• CacheControlFilter - controls the cache-related headers of
the response
• CharacterEncodingFilter - set the request body character
encoding when not already set by the client
• FacesExceptionFilter - solve 2 problems with exceptions
thrown in JSF methods: Mojarra's FacesFileNotFoundException
needs to be interpreted as 404 and root cause needs to be
unwrapped from FacesException and ELException to utilize
standard Servlet API error page handling.
• GzipResponseFilter - will apply GZIP compression on
responses whenever applicable
• HttpFilter - abstract filter specifically for HTTP requests

OmniFaces ViewScope
OmniFaces comes with a view scope that can be used in JSF 2.0/2.1.
Starting with JSF 2.2, we can use the built-in view scope, but, if we need to
immediately destroy @ViewScoped bean when browser window is unloaded
/closed then we need to come back to OmniFaces solution.
Starting with OmniFaces 2.2, the view scope was improved to immediately
destroy @ViewScoped on a GET navigation, or a close of browser tab
/window. These features are not supported by JSF 2.2.

OmniFaces utilities methods
OmniFaces comes with 300+ utilities methods that are available in
org.omnifaces.util package. We have utility methods based on JSF API
for AJAX, CDI Beans, messages, faces, events, callbacks, renderers, etc.
Most of them are useful to obtain a less verbose code, much easy to
understand, others provides hidden functionalities or simply comes with new
functionalities that are not easy to be achieved in JSF.
Read further: OmniFaces Utilities ZEEF Page by Anghel Leonard

OmniFaces utilities functions
OmniFaces comes with a comprehensive set of utilities functions in
org.omnifaces.el.functions package. These functions allows us to
easy manipulate objects, strings, arrays, dates, numbers, etc directly in page
via EL.
Read further: OmniFaces Utilities ZEEF Page by Anghel Leonard

References
• Bauke Scholtz - http://balusc.omnifaces.org/
• Arjan Tijms - http://arjan-tijms.omnifaces.org/
• JSF ZEEF page - https://jsf.zeef.com/bauke.scholtz
• OmniFaces ZEEF page - https://omnifaces.zeef.com/bauke.scholtz
• OmniFaces Wikipedia - http://en.wikipedia.org/wiki/OmniFaces

25+ Reasons to use OmniFaces in JSF applications

Recommended

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to 25+ Reasons to use OmniFaces in JSF applications (20)

Recently uploaded (20)

25+ Reasons to use OmniFaces in JSF applications