Tuesday, March 12, 2013

OmniFaces 1.4 is released! UPDATE: it's 1.4.1!

OmniFaces 1.4 has just been released! A little later than planned due to all the needed remaining work on FacesViews by Arjan Tijms which he blogged further about at Easy extensionless URLs in JSF with OmniFaces 1.4. Note that the OmniFaces showcase is now by default also configured to make use of it, and that it also got a new domain name, showcase.omnifaces.org, which also references an OpenShift application, but now with the HAProxy cartridge.


UPDATE: on March 12, one day later, the GzipResponseFilter of 1.4 was been reported to have an issue in Glassfish 3. This is tracked down to an if (!committed) block which was introduced during FacesViews testing. This change has been reverted and an 1.4.1 release is available at homepage and Maven. Please do not use the 1.4 release, but instead the 1.4.1!


Among the new things are:

Import functions

The handy <o:importConstants> now got a new brother: the <o:importFunctions> which allows you to import all public static non-void methods of a given class (usually an utility class) into the EL scope without the need to register them individually via a custom .taglib.xml file.


<o:importFunctions type="java.lang.Math" var="m" />

#{m:abs(-10)}
#{m:max(bean.number1, bean.number2)}

A (minor) disadvantage is that you'll miss intellisense/autocomplete in the average IDE.

Remove FacesServlet URL pattern from CSS/JS/image resources

The new UnmappedResourceHandler allows the developer to reference CSS background images in CSS resources without the need to clutter the CSS file with #{resource} expressions to reference CSS background images, which turned out to be a general maintenance pain when dealing with 3rd party libraries/plugins providing CSS/images (e.g. Twitter Bootstrap and several jQuery plugins).

Next to the <resource-handler> entry in faces-config.xml, you only also need to manually add the standard JSF resource URL prefix pattern /javax.faces.resource/* to the FacesServlet mapping in web.xml.

f:param with converter

Further, the standard <f:param> is been extended to implement ValueHolder interface in flavor of <o:param> and thus support a Converter. This is helpful in keeping the code DRY when you want to pass complex Java objects as a request parameter. I.e. you do not need


<h:link value="Edit Foo" outcome="/foo/edit">
    <f:param name="id" value="#{foo.id}" />
</h:link

anymore, but just


<h:link value="Edit Foo" outcome="/foo/edit">
    <o:param name="id" value="#{foo}" />
</h:link

provided that you've a @FacesConverter(forClass=Foo.class) which returns its id in getAsString().

An overview of what's new in OmniFaces 1.4

The below is basically taken over from the "What's new" page in the showcase.

Added in OmniFaces 1.4

  • Faces#getMetadataAttribute() and getMetadataAttributes() methods
  • New 'for' attribute in <o:validator> so that it can target inputs in composites
  • New TreeModel#getNextSibling() and getPreviousSibling() methods
  • of:coalesce() function
  • <o:importFunctions> taghandler to import public static non-void methods of a given type as EL functions
  • of:getMonth(), of:getShortMonth(), of:getDayOfWeek() and of:getShortDayOfWeek() functions
  • <o:param> which extends <f:param> with support for a Converter
  • UnmappedResourceHandler which removes the JSF prefix/suffix mapping from resource paths
  • Major overhaul of FacesViews; support for custom locations (including root) and extension, plus configurable actions when resource with extension or resource on configured path is requested
  • Programmatically getting list of welcome pages and checking if access is allowed to a URL according to security constraints
  • OmniFaces version will now be logged to webapp log in this format: INFO: Using OmniFaces version 1.4

Changed in OmniFaces 1.4

  • Support for Javabeans in Json#encode() as used by Ajax#data()
  • Recognize and workaround for JUEL 2.2.5 and before bug in <o:methodParam> (not needed for JUEL 2.2.6 and later)
  • Support spellcheck attribute on HtmlInputText and HtmlInputTextarea by Html5RenderKit
  • Support autofocus, pattern and placeholder attributes on HtmlInputSecret by Html5RenderKit
  • Delegate rendering to JSF when currently not in render response phase in FullAjaxExceptionHandler
  • Skip AbortProcessingException in FullAjaxExceptionHandler
  • Support java.util.TimeZone argument in of:formatDateWithTimezone()
  • Support com.example.SomeClass.SomeEnum on top of com.example.SomeClass$SomeEnum notation for inner enums in <o:importConstants>
  • Skip unrendered components during component tree visit of ResetInputAjaxActionListener
  • ELException will now also be unwrapped by FacesExceptionFilter and FullAjaxExceptionFilter in order to improve ajax exception handling in MyFaces

Bugfixed in OmniFaces 1.4

  • GzipResponseFilter incorrectly skipped gzip when the written data was not within servletcontainer's and Facelets buffer size
  • Fix initializaiton ordering problem of FacesViews in among others Glassfish server and removed accidentally introduced Servlet 3.0 dependency

Maven download stats

Here are the Maven download stats:

  • December 2012: 911
  • January 2013: 1427
  • February 2013: 1315

The months January and February average currently thus on nearly 46 Maven downloads per day, rounded down.

6 comments:

Daniel said...

Been waiting for this releade! Thanks guys!

Bauke Scholtz said...

@all: please check the update. Do not use 1.4, but use 1.4.1 instead.

anonymous said...

Thanks for new release, keep up the good work!

http://showcase.omnifaces.org/ is not working

Unknown said...

What is your opinion on JSF vs HTML5+CSS3+jQuery+JSON+REST? Maybe you could right an article/post about it?

Bauke Scholtz said...

@Rinaldo: it'll boil down to the same thoughts as I ever posted in this answer.

Theoretically, you could use JSF to create a component based approach of which does all the HTML5/CSS3/jQuery/JSON/REST works without the need to repeat all the boilerplate over and over.

Unknown said...

@Bauke Scholtz Thank you very much. The component approach does sound very interesting.

Although your answer on stackoverflow did cover some topics, I'm also interested in performance discussions. Do you know any article about it?

Again, thank you for always giving a very good answer.