Thursday, December 20, 2012

OmniFaces 1.3 is released!

OmniFaces 1.3 has just been released! It's hopefully on time before end of world ;)


Fist of all, OmniFaces 1.2 had some specific problems with processing ajax requests when RichFaces or MyFaces is been used. We just wanted to say "sorry" for any inconvenience caused by that, because this part should better have been tested, although it's after all not exactly our fault.

RichFaces' ExtendedPartialViewContext does (unexpectedly) not extend from PartialViewContextWrapper and hence it was never possible to obtain the wrapped OmniPartialViewContext from it. A reflection hack had to be used to fix that. MyFaces' PartialResponseWriterImpl does (unexpectedly) not use the getWrapped() method to delegate to the wrapped instance, instead it uses the local variable directly. OmniFaces' OmniPartialResponseWriter needs therefore to be changed to override all inherited methods to delegate to the wrapped instance, even though no additional tasks needs to be done (which actually defeats the whole point of the wrapper pattern). This was all fixed in the 1.3 snapshot of 21 November.

Restorable View

Now the Good News: next to a lot of relatively minor functions, a new select items index converter, a new bean validator, a "unique column" validator, a command script (the "standard JSF" variant of the well known PrimeFaces <p:remoteCommand>) and making the combined resource handler compatible with RichFaces resources, there's a completely new addition to the JSF world: the <o:enableRestorableView>.

The <o:enableRestorableView> is particularly useful for JSF web applications where server side state saving is been used. It basically instructs the view handler to recreate the entire view whenever the view has been expired. This effectively prevents ViewExpiredException on the view. This may be very useful on for example a registration or login page which is tied to a request scoped bean. This is also demonstrated as such on the showcase.

There are however (understandable!) technical design limitations: the recreated view is exactly the same as during the initial request, so any modifications which are made thereafter, either by taghandlers or conditionally rendered components based on some view or even session scoped variables, are completely lost. In order to recreate exactly the desired view, you would need to make sure that those modifications are made based on request scoped variables (read: request parameters) instead of view or session scoped variables. In other words, the state of the restorable view should not depend on view or session scoped managed beans, but purely on request scoped managed beans.

Thanks to Mimacom AG

Mimacom AG developers Adrian Gygax and Patrick Dobler have contributed to the biggest part of two new features of OmniFaces: <o:validateBean> and SelectItemsIndexConverter (which are further improved by yours truly). Thank you for your contributions, Adrian and Patrick!

New stuff

Here's a complete overview of all additions, changes and bugfixes in OmniFaces 1.3, see also What's new in OmniFaces 1.3? on the showcase application for links to live demos:

Added in OmniFaces 1.3

  • New Ajax#updateRow() and Ajax#updateColumn() (#82)
  • New <o:enableRestorableView> (#75)
  • New validationFailed attribute for <o:validateXxx> multiple field validators (#91)
  • New <o:validateBean> (#83)
  • New of:formatNumberDefault() (#90)
  • New <o:validateUniqueColumn> (#94)
  • New SelectItemsIndexConverter (#96)
  • New of:joinArray(), of:joinCollection() and of:joinMap() (#104)
  • New message attribute for <o:validator> (#109)
  • New <o:commandScript> (#108)
  • New of:addXxx() functions for date manipulation (#111)
  • New of:xxxBetween() functions for date calculation (#112)
  • New of:getDaysOfWeek() and of:getShortDaysOfWeek() functions for days of week (#58)

Changed in OmniFaces 1.3

  • Changed Html5RenderKit to support autofocus on HtmlCommandButton (#114)
  • Changed CombinedResourceHandler to recognize RichFaces specific resource libraries (#107)

Bugfixed in OmniFaces 1.3

  • Bugfix broken RichFaces PartialViewContext (#89)
  • Bugfix MyFaces issue with OmniPartialResponseWriter#getWrapped() (#99)
  • Bugfix o:tree initial state and tree visit (#105 and #106)

Maven download statistics

For the statsfreaks, here are the download stats from Maven:

  • October 2012: 831 (higher than expected during 1.2 release)
  • November 2012: 1024 (that's a nice geeky count!)

Container independent authentication

Arjan Tijms took for OmniFaces the effort to investigate the feasibility of a container independent JSF authentication module using the relatively unknown JASPIC API. After all, unfortunately, due to some container-specific bugs, JASPIC is not ready yet for inclusion in OmniFaces. Read more at his blog: Implementing container authentication in Java EE with JASPIC.


Unknown said...

"RichFaces' ExtendedPartialViewContext does (unexpectedly) not extend from PartialViewContextWrapper"

Have you file a RichFaces jira issue about this?

Even better would be a pull request resolving the issue ;)

Howard Smith said...

OmniFaces 1.3 release is yet another great OmniFaces release! I have been using OmniFaces since OmniFaces 1.1, and I have been using OmniFaces 1.3 ever since it's early/earliest SNAPSHOT version(s).

Thank you BalusC for the listening ear, responses, and any/all your contributions to JSF web app development!

Unknown said...

Hi BalusC,
Thank you for best JSF library.
My question/Problem
1. I'm try to use ExtensionlessURLs in Servlet 2.5 and got exception
13:49:11,031 ERROR [[FacesServlet]] Servlet.service() for servlet FacesServlet threw exception
java.lang.NoSuchMethodError: javax.servlet.http.HttpServletRequest.getServletContext()Ljavax/servlet/ServletContext;
at org.omnifaces.facesviews.FacesViewsForwardingFilter.doFilter(
at org.omnifaces.filter.HttpFilter.doFilter(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.omnifaces.filter.GzipResponseFilter.doFilter(
at org.omnifaces.filter.HttpFilter.doFilter(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.apache.catalina.core.StandardWrapperValve.invoke(
at org.apache.catalina.core.StandardContextValve.invoke(
at org.apache.catalina.core.StandardHostValve.invoke(
at org.apache.catalina.valves.ErrorReportValve.invoke(
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(
at org.apache.catalina.core.StandardEngineValve.invoke(
at org.apache.catalina.connector.CoyoteAdapter.service(
at org.apache.coyote.http11.Http11Processor.process(
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(

This mean it not support Servlet 2.5 how can I do for support Servlet 2.5.

2. GzipResponseFilter is not working on IE. I try to use FF/Chrome to browser web site it is reduce response file size but when use IE (IE8,9) it is not work.


BalusC said...

Smkid, thank you for your feedback. I have reported your issues as issue 123 and issue 124.

httPants said...

I'm testing the tag and have noticed that if I have a logon form on my home page, if a user loads that form, and i restart the server, if they then submit the form, the page just gets redisplayed and the form doesn't get submitted. The user then has to re-enter the form input values and resubmit the form again. Is this the expected behaviour of ? Is there a way to get the form submit to be resubmitted automatically if the view gets restored because of a session invalidation?