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.
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.
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> 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:
SelectItemsIndexConverter (which are further improved by yours truly). Thank you for your contributions, Adrian and Patrick!
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
<o:validateXxx>multiple field validators (#91)
of:addXxx()functions for date manipulation (#111)
of:xxxBetween()functions for date calculation (#112)
of:getShortDaysOfWeek()functions for days of week (#58)
Changed in OmniFaces 1.3
Html5RenderKitto support autofocus on
CombinedResourceHandlerto recognize RichFaces specific resource libraries (#107)
Bugfixed in OmniFaces 1.3
- Bugfix broken RichFaces
- Bugfix MyFaces issue with
- 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.