Posts

Showing posts from 2011

Automatic to-Object conversion in JSF selectOneMenu & Co.

-
When creating a web UI, there is often the need to let a user make a selection from e.g. a drop-down. The items in such a drop-down are not rarely backed by domain objects. Since these items in the HTML rendering are just simple character identifiers, we need some way to encode the object version of an item to this simple character identifier (its string representation) and back again. A well established pattern in JSF is the following: <selectOneMenu value="#{bean.selectedUser}" converter="#{userConverter}"> <selectItems value="#{bean.selectableUsers}" var="user" itemValue="#{user}" itemLabel="#{user.name}" /> </h:selectOneMenu> With userConverter defined as something like: @Named public class UserConverter implements Converter { @Inject private UserDAO userDAO; @Override public Object getAsObject(FacesContext context, UIComponent component, String value) { return use...
Post a Comment
Read more

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...
Post a Comment
Read more

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...
1 comment
Read more

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...
Post a Comment
Read more

Minimal 3-tier Java EE app, without any XML config

-
Image
Older versions of Java EE and Java frameworks in general were rather heavy with regard to required XML for configuration. Notorious were EJB2, Spring 2.x, JSF 1.x, Servlet 2.5 and many more. These days things have improved quite a lot. In this post I'll demonstrate a very simple, yet 3-tiered, Hello word application for Java EE. It uses JSF 2.1 and EJB 3.1 and absolutely not a single line of XML configuration. The entire application consists of just 3 files: page.xhtml , BackingBean.java and BusinessBean.java . To run the application, create a dynamic web project called 'mytest' in Eclipse (EE edition) and delete everything that's generated by default in WebContent. Copy page.xhtml to WebContent and copy both .java files to src. Add the app to your server (e.g. Payara 164) and browse to localhost:8080/mytest/page.jsf to see all the action. The following shows the code of the 3 files involved: page.xhtml <html xmlns="http://www.w3.org/1999/xhtml"...
Post a Comment
Read more

Stateless vs Stateful JSF view parameters

-
JSF defines the concept of view parameters, which are used to support URL parameters in GET requests (although it can be used for non-faces POST parameters as well ). View parameters are defined on a Facelet with the help of the f:viewParam tag. A typical usage looks like this: <html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core" > <f:metadata> <f:viewParam name="foo_id" value="#{myBean.fooId}" /> </f:metadata> <h:body> #{myBean.fooId} </h:body> </html> In this case myBean could look like this: @Named @ViewScoped public class MyBean { private Long fooId; public Long getFooId() { return fooId; } public void setFooId(Long fooId) { this.fooId = fooId; } } There's nothing really fancy going on here. When a GET request like localh...
Post a Comment
Read more