Posts

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

Where to put named queries in JPA?

-
JPA provides multiple ways to obtain entities. There is a very simple programmatic API that allows us to get an entity by ID, there's a more elaborate one called the Criteria API and then there's a query language called JPQL (Java Persistence Query Language). JPQL is an object oriented query language that is based on the simplicity of SQL, but works directly on objects and their properties. The problem with such a language that's used inside another language (Java) is where to store the query definition. Traditionally there have been 2 solutions: Store the definitions in annotations on some entity. Construct strings holding the definitions inline in your Java code. The first solution is called a Named Query in JPA, it looks like this: @NamedQueries(value={ @NamedQuery( name = "Website.getWebsiteByUserId", query="select website from Website website where website.userId = :userId") @NamedQuery(...) }) @Entity public class Web...
Post a Comment
Read more

Facelets and legacy JSP

-
It's well known that Facelets is the far superior technology when it comes to authoring pages using JSF. By default, Facelets has no provisions to include content from JSP pages, or Servlets for that matter. Normally this really isn't needed. Facelets provides a better and clearer templating mechanism than what JSP has ever offered. Facelets & JSP in one app However, when migrating a large application you might have to run a while in mixed-mode, that is running with both Facelets and JSP pages in a single application. It ain't pretty, but it is explicitly supported . Ever wondered why you are forced to use prefix mapping for this? Well, the Facelets view handler delegates to the default view handler for createView, which transforms a view ID suffix like .jsf or .xhtml to a default one (e.g. .jsp), but leaves the suffix alone when using a prefix mapping like /faces/*. The Facelets viewhandler later decides to handle a request itself or delegate again to the default...
Post a Comment
Read more