It’s feedback time! Developers today are presented with an abundance of options when selecting which technologies will form the basis of their applications. Even if we constrain ourselves to the presentation tier, that choices available are staggering. Technology providers then get to play the fun game of anticipating in which direction its users and customers are headed and make sure they are providing them with value. To help us at JBoss better understand in which direction you are headed with your applications of today and tomorrow, we have prepared a quick 3-question survey on Presentation Tier technologies.
JBoss Developer Framework The JBoss JDF project shows Java EE developers how to build state-of-the-art applications using the JBoss implementations of the Java EE stack. Specifically, the JDF View Frameworks section identifies a number of alternative approaches one can take when developing the view layer of your application. We in the RichFaces project have been working towards better supporting this effort by redesigning our JSF component architecture to allow the javascript part of our components (what we call our “widgets”) to be used independent of JSF, either in a standalone manner or coupled with another web framework.
Last week I was at Java One, where I can easily say I thoroughly enjoyed the week of chaos that is JavaOne. The quality of people and content was truly astounding - I met a number of people I’d been wanting to meet for a while, and also spent some time getting to know more fellow JBoss developers. I spent the bulk of my time preparing my presentations, leaving little time to attend sessions.
I’ll speaking next week at Java One on the topic of “Testing JSF Applications with Arquillian and Selenium. The Session co-ordinates are as follows: Testing JSF Applications with Arquillian and Selenium +CON7622: Thursday, Oct 4, 2:00 PM - 3:00 PM - Parc 55 - Cyril Magnin I Unfortunately the Java One website truncated the abstract, and the bit that’s left doesn’t give you a good idea of what I’m talking about.
It’s been a while since my last post, as I’ve gone through a significant career change. I am now working for Red Hat, as a core developer on the RichFaces project. I am also representing Red hat on the JSR-344: JSF 2.2 Expert Group, and will continue in my role as Seam Faces module lead. As such, I’ll be presenting at JAXConf/JSF Summit on the topic of Seam Faces. I really like this presentation, as I not only go into the features provided by Seam Faces, but I show how some of those features are implemented taking advantage of the platform extension points built into CDI and JSF.
JSF 2 introduced the ability to create RESTful URLs with the introduction of the <f:viewParam> tag. The tag is easy enough to use, you simply place it in the <f:metadate> tag, and configure the attributes to decode the url. <f:metadata> <f:viewParam /> </f:metadata> There are no words to explain how great a feature this is for JSF. The old “every request is a POST” theory didn’t pan out. RESTful URLs are bookmarkable, and meaningful to end-users.
At first the conversation scope introduced with CDI seemed like it would be incredibly useful. Unfortunately, working with conversations ended up being more difficult than expected. Details of why this is, is fodder for another post. I ended up often using the JSF ViewScope, exposed as a CDI scope though the Seam Faces CDI extension. When used in conjunction with JSF viewParams to propagate information between pages, the result is a book-markable end user experience.
Here’s how I show a notice on a JSF 2 page indicating that the JSF 2 postback failed due to validation errors. The following facelet snippet is rendered only when validation fails: <h:outputtext styleclass="errorMessage globalMessage" value="Request not saved due to input errors" rendered="#{facesContext.validationFailed}" /> The user then knows they should look through the page to correct the individually marked validation failures.
I’ve jumped on the JavaEE 6 bandwagon, with one application already in production. The developer productivity improvements in JavaEE6/Glassfish V3 are tremendous. The only downside is that I still have some JavaEE 5 applications in production. The JavaEE 5 apps can’t migrate to JavaEE 6 until Icefaces supports JSF 1.2. One workaround to this is to bundle the JSF 1.2 implementation with your application, then configure the classloader using the sun-web.
