Summary

Very good book on what is arguably the most popular JSF component library. Covers the less well used but very important ajax features of Richfaces, including the use of ajax regions, containers as well as the plug-n-skin features.

Details

To all intents and purposes, this book is not for a beginner JSF developer, because it assumes familiarity with JSF 1.2. It starts off by delving into the history of the Richfaces component framework, which in eons past was just Ajax4jsf. It gives a short introduction (which is expounded later) on the ajax capabilities, the component set and skinability features of Richfaces for Rich Internet Application development.

It then sets off showing you step by step, how to create a simple JSF application that takes advantage of Richfaces as it’s JSF components library. It presents the seam-gen tool, a nifty tool for creating skeletons jsf projects based on the JBoss Seam project. Following the instructions on seam-gen enables you to create a quick prototype to start playing around with. This is then followed by instructions on how to manually create a project which is not Seam based, for fans of other frameworks which also integrate JSF, or for the pure JSF purists. This also includes configuring facelets support, and finally a look at how the IDEs provide support for development using the Richfaces component set.

The rest of the book, chapter by chapter, then focuses on using Richfaces components in building an interactive, intuitive and rich UI for your JSF application.

The following chapter delves into creating a JSF application using seam-gen (which I felt was repetitive, given that they’d actually created one in the preceding chapter), with additional parameters for defining the persistence model (entities) that were to be used in the application. It is worth noting from here forward almost all the examples now make use of the Seam framework’s programming model, something which could be a problem for those who are not Seam adherents. Also, with the stated assumption that this book is targeted at people with a basic knowledge of JSF, there didn’t seem to be the need to go over the basics of templating with Facelets and defining managed beans in a faces-config.xml file.

The next two chapters then introduce us to the intricate details of what the application is actually supposed to look like in terms of UI and functionality. The reader is taken through creating a database and generating entities from these, as well as creating a login page. I felt that these two chapters were the weakest chapters of the book, seeing as they dwelt more on entities, JPA and entities generation and Seam’s identity and login management than it did on the particular component framework in question – Richfaces. This may be explained by the fact that Richfaces enables the user to hook into Hibernate Validator for DRY enforcement on the domain model, the user could have been spared the parts on how to create the database, etc as well as Seam’s login management features.

Subsequently, the next chapter gives some very good insight on skinning, and implementing a means for the user to dynamically change skins. It explains the Richfaces’s use of XCSS, a powerful xml based means of describing CSS properties, as well as how to use some of the default Plug-n-Skin examples.

Chapter 6 then takes us deep into a real ajax experience, showing us the lesser explored but very important features provided by the rich:dataTable and rich:column components, as well as the appropriate use of the datascroller component for displaying tabular data. It also talks extensively about other data iteration components like the DataGrid and the DataList. Additionally, it goes into detail on the appropriate use of ajax placeholders, especially on using Richfaces outputPanel in achieving really ajax based changes to UI after changes are made to content, instead of just using JSF’s rendered attribute only.

The next chapter then deals with using the RichEditor as well as how to implement Drag’n'Drop support in your application. Finally an in-depth score is done on using the Richfaces FileUpload component.

Chapter 8 and 9 deal into more detail with skinning support in Richfaces, including how to create your own Plug’n'Skin skins, which can be quite easy if you follow the author’s guidance.

Chapter 10 dwells on advanced ajax capabilities such as Poll, Push as well as the partial update of data iteration components in the UI.

Of course, this book would not have been complete without discussing the Richfaces Component Development Kit (CDK). From creating a maven project using Richfaces’s CDK archetypes, to creating your own user defined components and registering them with the application, this chapter covers it all.

It ends with an appendix giving a short description of all the components currently provided by the Richfaces team.

What I like about this book.

This book contains a lot of information about how to really take advantage of the ajax capabilities provided by the Richfaces framework, and makes important mention of very valuable points to look out for when ajaxifying your application. I highly commend the indepth knowledge of Richfaces placeholders and the use of attributes like ajaxSingle and process, which gives your JSF application a true ajax feel.

What I don’t like about this book.

I’m an avowed fan of JBoss Seam, but I’d have preferred the book didn’t delve so deeply into Seam to make it’s point. As i mentioned before, some chapters dealt more with Seam than with Richfaces, and those may actually be quite annoying to someone who is developing with say Spring Web Flow.

Packt Publishing has attempted to pull off a book that provides an indepth look at the 3.3 version of the popular JSF component library, Richfaces. In a lot of ways, I believe they have managed to do just that, give or take a few points.

I’ve had opportunity to use JBoss Seam from its 1.0 days, and also Spring Web Flow. I must admit that both frameworks really do hold their own in providing you with a full stack for rapid application development. This post does not attempt to look at these frameworks as a whole, but to focus on how easy it is to develop JSF
applications in them.

JSF is a Java standard for web application development. Therefore to judge any framework that depends on or claims to accelerate JSF, we will focus on how it scales over the gaping holes that are not handled by the standard, not just how they stick to it. Below are my observations. Note that the following points are not given in
any order of importance.

JSF’s UISelectItems Support

From somewhere in it’s 1.x version, Seam has provided the ability to use just a normal java.util.List of your own domain objects e.g. List<Student> directly to populate JSF’s UISelectItem controls like list boxes, drop down lists etc using their <s:selectItems/> component and it’s attached <s:convertEntity/> tag. Additionally, enums are easily handled in like manner using <s:convertEnum/> and <s:enumItem/>. This gets rid of the need to wrap domain objects in JSF SelectItem instances.

This is sorely lacking in Spring Faces, Spring’s JSF support for Web Flow, something I have even voted for in their JIRA instance.

Conversation Propagation in a Different Browser Tab

Seam provides the ability to invoke actions that start a new conversation or to move within states in a conversation using their provided <s:button/> or <s:link/> button and link respectively. Though Spring Faces has a Dojo backed
<sf:commandButton/> and <sf:commandLink/>, these are not yet capable of achieving this.

Integration with Hibernate Validator

Following the DRY principle, it can be very useful if JSF can also hook into the validation defined on your domain model using the defacto validation standard, Hibernate Validator. As you may already know, JSR-303 Bean Validation is targeted at standardizing the definition and enforcement of validation rules on your domain model,
with Hibernate Validator as the reference implementation. Seam provides the ability to enforce these validations in your JSF UI using the <s:validateAll/> tag.

Although requests have been made for this support, I’m yet to see it in Spring Faces.

Popup Screens

Sometimes it is cool to show modal panels for quick response from the user when interacting with the UI instead of a full page refresh. Spring Faces natively provides a Dojo based modal panel accessed just
by setting “popup” to true on any view state.

It is important to note however that though not natively supported in Seam, both it’s default JSF component library, RichFaces and the supported alternatives, ICEFaces and Trinidad, all provide this functionality
easily.

Display of byte[] images

JSF doesn’t provide any native control for the display of images from a byte array (byte[]) most probably retrieved from a database. The standard <h:graphicImage/> only deals with files accessible through a url. Seam however, provides support for display of images in a byte arrays using it’s <s:graphicImage/>.

There is no such support in Spring Faces, though RichFaces’s <a4j:mediaOutput/> could be used in displaying such content, however I have had problems using it with Spring Faces. ICEFaces also could be used to achieve this.

File Upload

Another vital component missing from the standard JSF toolkit is a file upload component of which Seam natively provides an <s:fileUpload/> component for achieving just that.

Unless you us a third party library like RichFaces or ICEFaces, I haven’t yet seen clear support for such a functionality in SpringFaces.

Rendering Components Based on Access Rights

Sometimes you want to hide a certain area of your UI from the user based on their roles/rights within the application. This is normally achieved in JSF using the “rendered” attribute on any tag or component. Seam provides a native way to easily hide or show components or sections using the s:hasRole EL function. An example of
this is below

<h:outputText value=”Hello”
rendered=”#{s:hasRole(‘Admin’)}”/>

This same support is extended to its “s:hasPermission” function, allowing you to render components on the UI based on not only roles, but fine grained permissions even backed by the Drools engine. And these functions are accessible whether on the UI, in your navigation rules (when you use pages.xml or pdl) and even in your code on annotations.

Spring Faces has no native support for this on facelets (I think it’s only available on jsps). However, an open-source project, Acegi-JSF, has a UI component tag <acegijsf:authorize/> and other additional ones which allow you to render based on access rights. This is limited, in that it cannot be applied to the rendered” attributes of JSF components since it is by itself a component/tag, not an EL function like Seam’s approach. You have to be quite inventive (and verbose) to come up with your own solutions to this problem.

Extended EL Capabilities

JSF 1.2 is limited in it’s EL support, and as a result you cannot invoke an action with parameters on a facelet. The following is not allowed, though I’ve seen proposals to fix it natively in

<h:commandButton action=”#{shop.buyProduct(product)}”/>

Seam uses it’s own implementation of the EL-API called the JBoss EL, and this allows the invocation of such actions in a facelet and in your navigation rules.

Though Spring Faces also uses JBoss EL, for some reason I haven’t been able to do anything like the above in my facelet, though it is possible in flow (it is a heavily used feature Spring Web Flow).

Automatic Detection of Converters & Validators Through Annotations

One may be forced to write some converters or validators needed to meet specific business logic needs. JSF requires you to specify these classes in it’s faces-config.xml file before being used.

Seam provides annotations for auto-discovering JSF converters and validators, meaning there is no need for the “xml hell” when creating these components.

Spring Faces doesn’t yet have this support.

TimeZones & Themes

The JSF specification assumes that all dates and times are UTC. To override this behaviour, a timezone must specified using an <f:convertDateTime/> on each date being displayed. The inconvenience of this cannot be overstated as I’ve had to deal with this. Using a Seam component on which the Time Zone may be specified in your application, Seam overrides this behaviour in your JSF application, a feature I’m yet to see in SpringFaces.

Also, most of today’s webapps come with the ability to change themes on the fly, but JSF has no native support for  themes. This support however is provided by Seam in a very easy to configure way, and is yet to make it to Spring Faces.

Tools

JSF by nature is designed with tools in mind, as result, tool support is an important part of adoption of JSF and every JSF framework’s tool support must be brought under the scope.

JBoss provides JBoss Tools, a superb set of tools for rapid application design. It’s Richfaces VPE provides wysiwyg, drag n’ drop design of facelets with a palette of HTML,JSF, Facelets and Richfaces components. It also supports resolution of your seam components inside facelet using Seam component names as well as wysiwyg declaration of
nagivation rules in both the standard JSF faces-config.xml or and Seam’s pages.xml. Even resolution of component names in code is also available. See the JBoss Tools Developer Guide for more on this toolset.

Spring provides it’s own Spring IDE set of tools which also allow the resolution of Spring beans within your flow definitions. Unfortunately, there isn’t any wysiwig support and Spring beans cannot be resolved by the Richfaces VPE.

Other Non-JSF Stuff For UI Developers

Conversation Switcher

With both frameworks promising the ability to have long running conversations, it then becomes useful to be able to start different conversations concerning different things, and have knowledge on the UI of which conversations have been started and the state in which the user is in each conversation.

This is natively supported in Seam but not in Web Flow.

Debug page

It helps to know the state and content of the beans in your scopes, especially when you want to know why certain things are not showing up on your facelet, without having to set break points in your IDE and start a whole debugging process.

Seam gives you the ability to at any time in any conversation, see the contents of your components in their appropriate scopes. This I sorely missed in Web Flow.

Summary

There are a host of other things that we could also compare, but from these ones it is not difficult to see why people who develop using the JSF framework see Seam as a saviour. We could choose
to chastise JSF itself for its shortcomings and use other frameworks but when someone comes along and makes standards like JSF more attractive as their first priority, I think they deserve the support and commendation. And that is what I believe is the problem with Spring Web Flow and it’s
Spring Faces project.

Spring has it’s own MVC framework, SpringMVC which predates Web Flow. Web Flow can be developed either using SpringMVC or JSF aka Spring Faces. A lot of the limitations of Spring Faces noted here are already handled natively by SpringMVC. Obviously, Spring Faces has not had the kind of attention that the first class citizen, SpringMVC
has in the world of Spring. In fact, one wonders if the sudden entrance of Spring Faces is not just a knee jerk reaction to Seam winning the JSF folks over.

I believe that if you had to develop a JSF application and did not have any investments in Spring already, it will make more sense to go for Seam as your preferred framework. Coupled with it’s advanced tooling, there isn’t as yet a better choice. Trust me, you won’t regret it.

Seam also has support for other web frameworks like GWT and Wicket. Though Seam’s support of Wicket is very young, it will be interesting to see what
the community’s acceptance of it is.

Technorati Tags: seam, web flow, jsf, jboss, spring

As part of DZone’s aim of informing the developer, especially Java developers of their choices in tools and technologies to be productive in their fields, it regularly publishes RefCardz. These are concise, straight to the point publications highlighting appropriate uses of different technologies. They have been very insightful to me.

In recent weeks, I’ve participated in reviewing the publication of Seam UI RefCard from Jacob Orshalick, the author of the just released Seam Framework: Experience the Evolution of Java EE and a committer on the Seam project. It contains some useful information on some of the best practices for managing and configuraing your Seam application’s UI. Just grap a copy here.

And just yesterday, a RefCard on Richfaces was published from the horse’s own mouth – Excadel. This publication features Nick Belaevski, Ilya Shaikovsky, Jay Balunas and Max Katz – author of the well acclaimed Practical Richfaces.

These give fans of Seam and Richfaces enough food for thought for the next few months. Enjoy chewing on them as I have.

< Seam PDF Rendering

Last week Geertjan Wielanga released a plugin he’d been working on for RichFaces tag support in NetBeans. I gave it a shot and its not bad.

Its meant to provide tag support as well as drag and drop of RichFaces controls on the palette. Interestingly this support is meant for both jsps and facelets. But seriously speaking, how many people are using RichFaces on jsps instead of on Facelets? Since this plugin only works with NetBeans 6.1 and the facelets support plugin does not work with 6.1, I really wonder what use it is to me and to a significant number of others.

This is really causing me to worry for Sun. Anyone doing anything new in JSF is not going with JSPs if they really know what is best for them, but rather with Facelets. If Sun really wants JSF to catch up (alongside using NetBeans as their preferred JSF development tool) then they should provide us developers with at least some of what JBoss Tools provides – visual editing. I’ve been waiting for Sun’s Visual JSF to now support Facelets, cos there’s no way I’m sticking with Rave. I think a lot of people share this sentiment and it is the reason why everyone is praising Seam for the good work its doing.

If Sun has seen it fit to bring Jacob Hookom onto the JSF 2 EG as a sign of respect for what Facelets stands for, then it should stop sitting on the sidewalk with Facelets support in NetBeans and get some decent support for it (and I mean not just tag support). Most of us NetBeans fans are in a love hate relationship with it because of such political (in)decisions. Sun should continue taking developers seriously and see how to improve on it’s technologies with already proven ones instead of trying to stuff things down our throats that we don’t want to swallow.

Ah. I just came across a release of the Facelets support for NetBeans 6.0 rebuilt to work with NetBeans 6.1. Good job by http://ifnu.artivisi.com. Here is the download. And thanks to Po-Ting Wu for the rebuild instructions.

Thanks also to Geertjan for the work on Richfaces support. JSF development will get better and easier!

<Seam 2.0 on Tomcat … | Seam Portlet Bridge Released >
RichFaces 3.1.3.GA came with a some new controls, and the <rich:listShuttle/> was of some interest to me. However, for a particular use case I found it not sufficient for my needs, and had to roll out my own version of it with a little bit of Ajax to add.

Let me use this simple scenario to display what I needed to do. Assuming you were keeping a shopping cart. After users select an item they want to buy, you want them to specify the quantity of that item following which their total charge is calculated for them on the fly. This I thought of doing using two DataTables just like the <rich:listShuttle/> appears but on a sleeker (or is it cruder?) level.

I defined an interface with a simple set of methods which I felt would do the trick called InPlaceEditing.

public interface InPlaceEditing {

void editSelection();

void addSelection();

void removeSelection();

void cancelSelection();

}

Here is my”shopper” Seam component which implements the interface. Notice the use of 2 DataModels “products” and “selectedItems” and their corresponding DataModelSelections. This is to enable me select from one table to another.

@Name(“shopper”)

@Scope(ScopeType.CONVERSATION)

public class Shopper implements java.io.Serializable, InPlaceEditing {

private boolean edit;

@In

EntityManager entityManager;

@In

FacesMessages facesMessages;

@DataModel

List<Product> products;

@DataModelSelection(“products”)

private Product product;

@DataModel

private List<CartItem> selectedItems;

@DataModelSelection(“selectedItems”)

private CartItem selectedItem;

@Out(required = false)

private CartItem cartItem;

private BigDecimal total = new BigDecimal(0.0);

private static int count = 0;

@Begin(flushMode=FlushModeType.MANUAL)

public void beginShopping() {

products = entityManager.createQuery(“Select p from Product p”).getResultList();

selectedItems = new ArrayList<CartItem>();

}

The beginShopping() method starts a conversation and FlushMode is set to MANUAL. This means that all changes made to entities will be made persistent only if I call flush() on entityManager. Seam defaults to AUTO which means all changes to all managed entities are merged into the persistence context after every Seam action call. Trust me, for the purposes of this trick, you DON’T want automatic persistence context merging! Anyway this action populates the “products” DataModel with products already entered into the database. The result is the table below.

<a:outputPanel id=”productPanel”>

<rich:dataTable value=”#{products}” var=”product”>

<h:column>

<f:facet name=”header”>Product</f:facet>

<a:commandLink value=”#{product.name}” actionListener=”#{shopper.editSelection}” reRender=”editPanel”/>

</h:column>

<h:column>

<f:facet name=”header”>Price</f:facet>

#{product.price}

</h:column>

<h:column>

<f:facet name=”header”>Stock</f:facet>

#{product.stock}

</h:column>

</rich:dataTable>

</a:outputPanel>

A look at the section of the shop.xhtml facelet shows an <a:commandLink/> – an Ajaxified version of the <h:commandButon/>. This supplies our “shopper” component with the selected product through the “product” data model selection through Ajax. Also take note of the “reRender” and <a:outputPanel/> tags, which specify which areas of our page should be Ajax refreshed after certain actions are called. In the editSelection() action a new CartItem (a join entity between a product and a shopping cart) containing the selected product is created and outjected.

public void editSelection() {

if (edit == false) {

cartItem = new CartItem();

cartItem.setId(count++);

cartItem.setProduct(product);

cartItem.setSelected(true);

return;

}

cartItem = selectedItem;

cartItem.setSelected(true);

edit = true;

}

I want to use the same action to represent selecting a new product (from “products”) and editing an already existing CartItem (from “selectedItems”). This is achieved with a private “edit” boolan field, which by default is false. Also since proper behaviour of DataModel and DataModelSelections depends on a properly implemented equals() method (i.e. instance uniqueness) I assigned artificial ids with the static “count” to each CartItem. Note that without setting flushMode to MANUAL, doing this will cause exceptions to be thrown down the lane somewhere. Finally setting the CartItem’s “selected” field to true enables the rendering of the panel in which the quantity of that product will be entered.

Once the quantity is specified, the addSelection() action is called. Because of the boolean “edit” we are able to determine if this is a new product selection or one from the existing list and respond appropriately, calculating the total cost of the users purchases so far and modifying the corresponding DataModels appropriately. In the case of an edit, the old computed cost of a product is deducted from the total, and re-computed and added to the total. To guarantee that the change in costs will reflect properly, the edited “cartItem” is removed and re-inserted in to the “selectedItems” DataModel.

It is also very easy to remove an already configured CartItem, again with the combination of <a:commandLink/> and the “selectedItem” DataModelSelection.

public void removeSelection() {

total.subtract(selectedItem.getCost());

selectedItems.remove(selectedItem);

}

Finally, the user may save their selection. This involves the creation of a new Cart object, which is persisted to get an ID and associated with the CartItems in the “selectedItems” DataModel. Note here that the fake Ids I generated for the CartItems will cause maximum trouble in the database, and so I set them to null to force the persistence context to generate proper Ids for them. Don’t forget the all important “entityManager.flush()” to make all changes permanent.

Finally I raise an event (“shopper.events.CartEdit”) which is being observed by the “shopList” Seam component’s list() action causing the “carts” DataModel to be refreshed with fresh data.

@Factory(“carts”)

@Observer(“shopper.events.CartEdited”)

public void list(){

Contexts.getSessionContext().set(“carts”, null);

carts = entityManager.createQuery(“Select c from Cart c”).getResultList();

}

The Job Is Done. This is use of Ajax and DataTables is quite simplistic, but I’ve used it in some really tight corners for some advance stuff. One scenario that I can see with this example is the requirement to remove a product from the list of products once selected and configured, or to put it back once it has been removed from the configured ones. Another will be how to edit an already persisted cart to remove or add products to that cart. I’ve just laid the foundation. With some tricks of your own, you should be able to achieve some serious magic.

< @RequestParameter and @Observer usage | Ajax Magic with DataTables >

Recently I’ve had need to begin developing a new application using Seam. However this time I’ve decided to go lightweight, so the obvious choice was Tomcat 6. I realized that the Seam plugin for NetBeans was limited to project generation for JBoss and so wasn’t an option. I decided to create everything on my own. Thankfully there is an example of the booking application with build scripts for Tomcat 6, Glassfish, WebLogic and WebSphere under jboss-seam-2.0.GA/examples/jpa. So here’s how you can set up yours work on Tomcat 6.

First, build the tomcat example by running ant tomcat6, which generates 2 folders – dist-tomcat6 and exploded-archives-tomcat6. With that done, create a library in NetBeans which you’ll add it to your project. I called mine “Seam4Tomcat” and added all the jar files in jpa/exploded-archives-tomcat6/jboss-seam-jpa.war/WEB-INF/lib.

Then create the project itself. Select the “Web Application” project type, specify Tomcat 6 as the target server and JavaEE 5 as the version of JavaEE. Next check Facelets as the framework to be used and create the project. Right click on the project and select “Properties”. Select “Libraries” on the left panel and “Add Library” to add your Seam4Tomcat (or whatever name you gave it) jars to your project. Remember to uncheck the Facelets related libraries provided by the NetBeans facelets support, since they are already in you newly added library.

Since the Seam filter needs to be installed to allow seam integration (as well as other configurations), just copy the contents of jpa/exploded-archives-tomcat6/jboss-seam-jpa.war/WEB-INF/web.xml and paste them in your web.xml file. You may change the <url-pattern> under the “Faces Servlet” servlet mapping to the url you want from the default “*.seam”.

Append this to the top of the web.xml file to add the blueSky RichFaces skin to RichFaces components you might use in the application.

<context-param>

<param-name>org.ajax4jsf.SKIN</param-name>

<param-value>blueSky</param-value>

</context-param>

Note that your faces-config.xml will already contain the reference to the Facelet view handler as well after creating the project.

Next, Seam gives you advanced navigation in its pages.xml file compared to JSF’s faces-config.xml file. To use it, just copy the jpa/exploded-archives-tomcat6/jboss-seam-jpa.war/WEB-INF/pages.xml into your WEB-INF folder. Also add the components.xml from the same directory to your WEB-INF folder. This is the most central file to any seam application and must always be there.

We’ll need to connect to some database to begin work with. So right-click your project, go to “New” and select “Entity Classes from Database”. We’ll assume no existing datasource and create one from an existing database connection. Drop down the “Data Source” combo box and select “New Data Source”. Enter a jndi name (mine is “jdbc/example”) and select the database connection. Enter the username and password for connecting to that database and your tables will be displayed.

Select the tables you want to generate entities for and click “Next”. You are then given the chance to edit the names of the Entities to be generated as well as specify the package within which they will be kept (mine is “example.entity”). NetBeans can generate named queries for you, but more importantly any JPA project needs a persistence unit. This consists of your entities and an ever so vital persistence.xml or orm.xml file.

Click the “Create Persistence Unit” button to create a persistence.xml file. Enter a persistence unit name (note the name you give. It will be used later). Specify your persistence provider – NetBeans comes with TopLink, but for Seam Hibernate is the better persistence provider. Note that I’ve changed the “Data Source” from “jdbc/example” to “java:comp/env/jdbc/example”. This is the fully qualified JNDI name that will be used by the container to resolve the EntityManager resource we’ll be injecting into our code. Since our database tables already exist, we’ll select “None” for “Table Generation Strategy” and click “OK”. We are finished with everything now and will click “Finish” to end the wizard.

The preceding process creates two very important files: context.xml and persistence.xml files. Every resource that would be used in Tomcat should be declared in context.xml as a resource. Here is mine from the process above. You are free to tweak yours as the need may be.

<Context path=”/example”>

<Resource auth=”Container” driverClassName=”com.mysql.jdbc.Driver”

maxActive=”20″ maxIdle=”10″ maxWait=”-1″

name=”jdbc/example” password=”" type=”javax.sql.DataSource”

url=”jdbc:mysql://localhost:3306/knust” username=”edem”/>

</Context>

Here is my persistence.xml file as well. Note that I have changed the transaction-type to “RESOURCE_LOCAL” from “JTA”. However Seam provides JTA support for our application and therefore the <jta-data-source> declaration instead of <non-jta-data-source>. These must be exactly as it is here or your application will DEFINITELY give you errors.

<persistence-unit name=”exampleDatabase” transaction-type=”RESOURCE_LOCAL”>

<provider>org.hibernate.ejb.HibernatePersistence</provider>

<jta-data-source>java:comp/env/jdbc/example</jta-data-source>

<properties/>

</persistence-unit>

</persistence>

Now go back to your components.xml file. If you did copy the one from the exploded jpa example, you should have the following declaration in this file.

<core:manager conversation-timeout=”120000″

concurrent-request-timeout=”500″

conversation-id-parameter=”cid”/>

<transaction:entity-transaction entity-manager=”#{em}”/>

<persistence:entity-manager-factory name=”bookingDatabase”/>

<persistence:managed-persistence-context name=”em”

auto-create=”true”

entity-manager-factory=”#{bookingDatabase}”/>

<security:identity authenticate-method=”#{authenticator.authenticate}”/>

First things first. Replace all instances of “bookingDatabase” with the name of your persistence unit (I told you to take note of that – mine is “exampleDatabase”). Secondly, by giving the name “em” to all references to EntityManager and managed persistence contexts, it means that your code can only inject the EntityManager under the same name like so

@In EntityManager em

If you use a different name to inject it don’t say I didn’t tell you about the errors you’ll be getting. Alternatively you could change it to “entityManager” or whatever, just make sure that you use the same name as declared in components.xml throughout your code.

The last but often most forgotten thing that needs to be added is a seam.properties file. I can recount the number of times I’ve had nightmarish debugging sessions when a fresh application I’d just created to display Seam to someone didn’t work because of this file. In NetBeans, just right-click the project, select “New” and the “Properties file”. Call it “seam” and do not put it in any package (which puts it in default).

With all this done, you are good to go developing for Tomcat 6 using Seam. NetBeans offers some level of incremental deployment to Tomcat, detecting if Java classes have changed and redeploying the application. However, since NetBeans remotely deploy web applications to Tomcat, Tomcat will be reading from your project folder directly to deploy the application. This means that some changes like changes made to your facelets page will immediately appear on your web-browser. Just save the changes you make to a facelet, refresh your web browser and boom! For me that is enough. Tomcat deploys quickly and so redeploying when a Java class changes is not that painful.

Here’s an application I created to display this process to a mate. It’s got all the configurations files, some entities and Seam components to get you started.

<Simple DataTable Example | Seam on Tomcat >

One good thing that Seam adds to JSF is the ability to use GET requests to retrieve data. The JSF spec decided to make every request a post, and this makes it difficult to bookmark pages or fetch pages directly from entering a url along with some parameters.

Well see how this problem is solved in Seam using a simple annotation: @RequestParameter. This annotation allows us to pass a request parameter to our Seam component. Its value is injected before any method is called, guaranteeing us that the request paremeter will be available to us to make use of in our code. A look at our previous example shows us that departmens belong to specific faculties. This means we will need to pass the particular faculty whose departments we want to see on our departmentList.xhtml page displaying departments. Here’s the code that does it in our departmentListing Seam component:

@Stateful

@Name(“departmentListing”)

@Scope(ScopeType.SESSION)

public class DepartmentListBean implements DepartmentList {

@PersistenceContext(type=PersistenceContextType.EXTENDED)

EntityManager em;

@DataModel

List<Department> departments;

@DataModelSelection

private Department department;

@In FacesMessages facesMessages;

@RequestParameter

Integer facId;

@Out(required=false,scope=ScopeType.SESSION)

Faculty faculty;

@Factory(“departments”)

@Observer(“univseam.event.DepartmentChanged”)

public void departmentList() {

//select if a faculty id has been passed to us

if(facId != null){

try {

faculty = (Faculty) em.createQuery(“Select f from Faculty f where f.id=:id”).

setParameter(“id”, facId).getSingleResult();

} catch (NoResultException exception) {

facesMessages.add(“Non-existent faculty passed!”);

return;

}

}

//if the faculty is not null then select its departments

if (faculty != null) {

departments = em.createQuery(“Select d from Department d where d.faculty=:faculty”).

setParameter(“faculty”, faculty).getResultList();

return;

}

facesMessages.add(“No departments under this faculty yet”);

}

Our list of departments is as shown below.

The “facId” is a request parameter passed from the page displaying the list of faculties. The method departmentList() is annotated with @Factory(“departments”), which forces Seam to load up the list of departments into the “departments” ArrayList. Seam guarantees that the faculty id will be properly converted to an Integer and placed in the facId variable before we initialize our list of departments, enabling us to first select the particular faculty and pass it to the query to load the departments. Outjecting the faculty object to the Session context is necessary to this discuss and we’ll see why soon.

But how was the request parameter passed? Well, the simple <f:param> tag in JSF allows use to do that. Take a look at this portion of the facultyList.xhtml facelet.

<h:column>

<f:facet name=”header”>Action</f:facet>

<s:link value=”Departments” view=”/departmentList.xhtml”>

<f:param name=”facId” value=”#{faculty.id}”/>

</s:link>

</h:column>

With the use of an <s:link> we are able to append the faculty id to our URL under the name facId and seam binds to that name using the RequestParameter.

Not only is RequestParemeter useful in searching, but can also be very helpful in determining if an entity is being edited or a new one being created. Here we are with a list of departments. We want to use the same page to edit as we do for new department creation. RequestParameter to the rescue.

@Stateful

@Name(“departmentManager”)

public class DepartmentManagerBean implements DepartmentManager {

@In

EntityManager entityManager;

@In

FacesMessages facesMessages;

@In

Faculty faculty;

@Out(required=false)

private Department department;

@RequestParameter(“depId”)

Integer depId;

public void createDepartment() {

//if the department already exists, then allow an edit

if(depId != null){

try {

this.department = (Department) entityManager.createQuery(“Select d from Department d where d.id=:id”).setParameter(“id”, depId).getSingleResult();

} catch (NoResultException noResultException) {

facesMessages.add(“Invalid department”);

}

facesMessages.add(“Editing a department”);

return ;

}

//else instantiate a new department entity

this.department = new Department();

this.department.setFaculty(faculty);

facesMessages.add(“Creating a new department”);

return;

}

Passing the department id enables us to find out if a department like this exists already, in which case we load up that department for editing. If not we create a new department instance, passing it the faculty to which it belongs (which we injected from the previously outjected instance).

Look at how this is done in the departmentList.xhtml facelet.

<h:column>

<f:facet name=”header”>Action</f:facet>

<s:link id=”edit” value=”Edit”

view=”/department.xhtml” action=”#{departmentManager.createDepartment}” propagation=”begin”>

<f:param name=”depId” value=”#{department.id}”/>

</s:link>

</h:column>

The page for modifying/creating a new department is below

Again this appends the department id as depId to the URL, and Seam makes it available to our departmentManager to use before the createDepartment method is called. Through this the department.xhtml facelet can be used both for creation and editing of department entities.

I’ve also been looking at alternative ways of automatically refreshing a list when a new element has been added to it in the database. Since @Factory is called only if the referred to object is null, we need another way to reload the list of departments and add the new department as well. Seam has an event mechanism based on the Observer pattern. This allows me to raise events, and all observers of that event immediately get notified of it. After populating the fields of a department I call saveDepartment, which saves my entity to the database. I then raise my own pretentious event: “univseam.event.DepartmentChanged”.

@End

public String saveDepartment() {

if(department.getId()!= null){

entityManager.merge(department);

facesMessages.add(“Department updated!”);

}else{

entityManager.persist(department);

facesMessages.add(“New department added!”);

}

Events.instance().raiseEvent(“univseam.event.DepartmentChanged”);

return “success”;

}

Notice that the factory method that initializes the list of departments (displayed previously) is also annotated with @Observer(“univseam.event.DepartmentChanged”). This time the facId will be null, but faculty is still in session scope, so we are able to reload the list of departments as if it’s nobody’s business.

Seam events enable applications to be very stateful, updating themselves when changes happen on the fly. Combining it with request parameters even makes it more fun to do.

]]> http://edemmorny.wordpress.com/2008/01/24/bookmarkable-parameters-and-the-events-model-in-seam/feed/ 15 Edem old dept list new department creation Updated list of depts http://edemmorny.wordpress.com/2008/01/19/annoying-netbeans-60-facelets-support-issue-on-tomcat/ http://edemmorny.wordpress.com/2008/01/19/annoying-netbeans-60-facelets-support-issue-on-tomcat/#comments Sat, 19 Jan 2008 15:56:56 +0000 Edem Morny http://edemmorny.wordpress.com/2008/01/19/annoying-netbeans-60-facelets-support-issue-on-tomcat/ ]]>

Yesterday i got a call from a good friend of mine who has been dipping his fingers into JSF a bit. He’d decided to jump ship to using JSF on XHTML files, a technology known as Facelets. So he goes to download NetBeans 6.0 Facelets support plugin and installs it.

After developing a simple facelets page, he decides to deploy it to Tomcat 6.0.14 only to get BIG FAT class loader exceptions. What better way to treat a sceptic who is just getting into the game of web development in Java. These are the kind of things that can be so annoying about doing something in Java. Being a Seam advocate and user, I didn’t immediately realise what could have been the problem, since my Seam applications run fine using the jars from Seam.

After doodling around and making some changes to jars that came with the Facelets support, i just decided to ditch the jars from Facelets support and use my own. I picked the jars that come with Seam and VOILA! Problem solved. Makes me wonder if the guys who developed the plugin didn’t try to deploy it themselves AT LEAST to Tomcat before putting it out there. Anyways i just felt like putting up the solution to this simple but very annoying problem here for the sake of those who might try an introduction to Facelets.

Note that i got these jars from the JBoss Seam 2.0.GA’s lib folder. I can’t tell you where u can get them individually but downloading seam altogether will give you a change to start playing around with it if you haven’t started already.

Simply create a new Library in NetBeans by going to Tools->Libraries. I gave mine the name Facelets4Tomcat. Here are the jar files you need.

• commons-beanutils.jar
• commons-collections.jar
• commons-digester.jar
• commons-logging.jar
• jboss-el.jar
• jsf-api.jar
• jsf-facelets.jar
• jsf-impl.jar

This goes into your web.xml file.

<context-param>
<param-name>com.sun.faces.validateXml</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
<param-value>.xhtml</param-value>
</context-param>
<context-param>
<param-name>facelets.DEVELOPMENT</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>facelets.SKIP_COMMENTS</param-name>
<param-value>true</param-value>
</context-param>
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.jsf</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>forward.jsp</welcome-file>
</welcome-file-list>

If you want to add the Ajaxified RichFaces components then add the following from the same Seam lib folder.

• richfaces-api.jar
• richfaces-ui.jar
• richfaces-impl.jar

And add these to the top of your web.xml file

<filter>
<display-name>RichFaces Filter</display-name>
<filter-name>richfaces</filter-name>
<filter-class>org.ajax4jsf.Filter</filter-class>
</filter>
<filter-mapping>
<filter-name>richfaces</filter-name>
<url-pattern>*.jsf</url-pattern>
</filter-mapping>
<context-param>
<param-name>org.ajax4jsf.SKIN</param-name>
<param-value>classic</param-value>
</context-param>

You may use a different skin if you want. Check out the documentation for details

You may then add the library you created to your project by right clicking your web project and selecting “Properties”. At Libraries, click “Add Library” and selected the library you just created. Make sure that the check box is enabled or else it will not put the jar files in the right location i.e. WEB-INF/lib.

Oh, and MAKE SURE that the Facelets support libraries are unchecked, or else you’ll be back to square 1.

Happy Faceleting.