Posts

Showing posts from September, 2011

Jakarta EE Survey 2020

At OmniFaces we poll the community from time to time about Java EE (now Jakarta EE) and related technologies. With the transfer of Java EE to Jakarta EE now almost completed, people are now starting to think about Jakarta EE 10 , the first Jakarta EE release after Java EE 8 having new featues. As such it's a good time to poll the community again. In the 2020 edition, there are 4 categories of questions again: Current usage of Java EE / Jakarta EE Servlet containers APIs related to Java EE / Jakarta EE The future of Jakarta EE Compared to 2018, we simplified some of the questions somewhat, omitting some of the less popular options to make it more manageable. We added questions about the future of Jakarta EE and MP together, the preferred Jakarta EE cadence, and generally updated the choices (such as adding Quarkus , which wasn't quite on the radar in 2018 and our own Piranha Cloud ). Jakarta EE provides the opportunity to revitalise and modernise Java EE, but i

Single class pure Java JSF application

Image
In my previous blog entry, Authoring JSF pages in pure Java , it was explained how to set up a JSF based web application using nothing but pure Java. No XML based templating (Facelets) was required and the view was build purely programmatically. I got one remark though that the example code did used expression language (EL) to patch some of the parts together. Although EL is really convenient, as it provides a way to point to a (nested) method on a scoped object, it's not regular type-safe Java. Luckily, the Java component API of JSF doesn't only use EL based ValueExpressions and MethodExpressions, but also allows regular Java types to be set as listeners and values. This is demonstrated in the code below. While at it, I've done away with the separate backing bean for this example and let the same class that defines the page handle the action event. The result is a pure Java, xml-less, EL-less, config-less, single class JSF application [phew]: @Named @FacesConfig p

Authoring JSF pages in pure Java

Image
JSF is well known as a server side web framework to build a web application's UI with the help of components. For the overwhelming majority of users those components are represented by the tags one uses to compose a page, be it via JSP or Facelets. The following is a typical example of a page authored with Facelets: <html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html"> <h:body> #{backingBean.hello} <h:form> <h:inputText value="#{backingBean.name}" /> <h:commandButton value="Say Hello" action="#{backingBean.sayHello}" /> </h:form> </h:body> </html> This may give the impression that JSF components *are* the tags shown above, and thus that JSF is necessarily about tags and XML. That is however not true. JSF has always had a clear separation between th

Simple Java based JSF custom component

Even though in JSF components have always been a central thing, actually creating them required a ridiculous amount of tedious work in JSF 1.x. Not only did you had to create the actual component, it also required you to: Register the component in an XML file Create a tag handler class, where you referenced the component by its registered name Register the tag in .tld file. You were also more or less supposed to create a separate renderer class, and although this actually has always been optionally, people seemed to interpret it as being a required part as well. Although none of this was really difficult, the sheer amount of work prevented everyone but component library builders from creating components. JSF 2.0 addressed all of these concerns by introducing composite components , where you are able to create first-class components just by putting some existing components and/or markup in a Facelets file. For the majority of use cases where application builders needed their