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()
andgetMetadataAttributes()
methods- New '
for
' attribute in<o:validator>
so that it can target inputs in composites - New
TreeModel#getNextSibling()
andgetPreviousSibling()
methods of:coalesce()
function<o:importFunctions>
taghandler to import public static non-void methods of a given type as EL functionsof:getMonth()
,of:getShortMonth()
,of:getDayOfWeek()
andof:getShortDayOfWeek()
functions<o:param>
which extends<f:param>
with support for aConverter
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 byAjax#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
andHtmlInputTextarea
byHtml5RenderKit
- Support
autofocus
,pattern
andplaceholder
attributes onHtmlInputSecret
byHtml5RenderKit
- Delegate rendering to JSF when currently not in render response phase in
FullAjaxExceptionHandler
- Skip
AbortProcessingException
inFullAjaxExceptionHandler
- Support
java.util.TimeZone
argument inof:formatDateWithTimezone()
- Support
com.example.SomeClass.SomeEnum
on top ofcom.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 byFacesExceptionFilter
andFullAjaxExceptionFilter
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:
Been waiting for this releade! Thanks guys!
@all: please check the update. Do not use 1.4, but use 1.4.1 instead.
Thanks for new release, keep up the good work!
http://showcase.omnifaces.org/ is not working
What is your opinion on JSF vs HTML5+CSS3+jQuery+JSON+REST? Maybe you could right an article/post about it?
@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.
@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.
Post a Comment