JSF Applications – JBoss Seam or Spring Web Flow?

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

DZone Releases Richfaces and Seam UI RefCardz

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.

JBoss Tools, Seam and XML Editing

I’d never been a fun of xml files. Never. I like to put my money where my mouth is, and that is not in xml files. Then came EJB3. And just when I was getting settled down with the new craze (Annotations), along came Seam. Now I could happily run away from my EJB 2.1 days of verbose xml and never go
down the trail of “xml hell” again, editing xml just when i
really, really need to. Alas, twas just a dream. When you are faced
with an application that needs to be flexible and extensible,
sometimes the best (and probably only) way is through xml. And that
is exactly what I was faced with recently. However, JBoss reminded me
of one of the reasons why Seam is a compelling choice of framework –
tools support through JBoss Tools. Now I’ve fallen in love with xml
editing – simply because I don’t have to do any.

Here’s the scenario. Let’s say I were
developing an application for playing games, allowing users to play
different games which obey a consistent API. This means a separation
into interfaces and implementations. Here is how I tried to create
that separation.

• Plugnplay-api – consistent
  interfaces that are to be coded to.

• Plugnplay-impl – implementations
  of the above api. Contains Seam components (i.e. Entities, Actions,
  UI components etc).

• Plugnplay-web – the basic Seam
  application (here’s where the facelets as well as the aforementioned
  components finally end up).

This meant that I’d have to use the
components.xml file to specify the names (instead of @Name) as well
as other properties of my Seam entities and actions. No hustle. I
immediately realized how big such a file will get. Thankfully Seam
allows you to define one components.xml file for each component like
Hibernate (not my idea of fun) or one components.xml file per
package. I chose the second option and decided to put JBoss Tools to
work. The result was pleasing. Let’s look at mapping different
implementations of the Game interface – DominoGameImpl and
MonopolyGameImpl.

1. Select File -> New -> Other.

2. Scroll to XML subcontent and
   select XML.

3. Enter the name “components.xml”
   as file name and click Next.

1. In the “Create XML File From”
   screen, choose “Create an XML file from an XML schema file”.
   This forces our xml file to conform to a schema, in this case the
   components-2.0.xsd from Seam. Click Next.

2. At XML Schema File, select “Select
   XML Catalog entry”. This should show a list of all schema files
   currently registered in your Eclipse installation.

3. 

4. Scroll through the XML Catalog and
   find the key “http://jboss.com/products/seam/components-2.0.xsd”.
   Click Next.

5. At the Root Element dialog box,
   change the default Root element of “action” to “components”.
   This is the root element in all components.xml files, and allow
   other child elements such as pdf, mail etc. You may leave the other
   checkboxes as their default. Click Finish to end the wizard.

   

Finally our components.xml file is
created and displayed in the Seam Components Editor. At this top
level we can add components, define factories, events and imports.
Without much ado we’ll add our Game components. This is the part I
love the most.

1. Click “Add” to add a seam
   component.

2. Enter the name of the Seam
   component.

3. To add the particular class, click
   Browse. You have a window with 3 tabs – “Search”, “Browse”
   and “Recent”.

4. In “Search” begin typing the
   name “DominoImpl” as our Seam component. A dynamic list of
   matching classes are displayed as you type to select the particular
   one you want.

1. Select the appropriate class and
   click “OK”.

2. In the Seam Components Editor, you
   may now specify the scope as well as other properties. I’ll choose
   CONVERSATION from the Scope drop down list. Press Ctrl+S to save.

3. Repeat these steps to add the
   MonopolyGameImpl as a Seam component.

Now that we have our games, we want to
associate them with a particular user. Our User API defines a list of
Games as a field. We repeat the above process in the “admin”
package, selecting UserImpl as with the component name “user”.
Set the scope of the component as you wish.

To add properties to the “user”
component do the following.

1. Click on it in Component Editor.
   In the Properties sub-section, click on Add… . You immediate get
   three options to select from; “Add Simple Property”, “Add List
   property” and “Add Map property”.

2. Choose the 2^nd option.
   In the dialog box that appears give our list the name “games”,
   mapping to the getGames and setGames of the UserImpl. We can now add
   values to the games list. Add the name “monopoly”.

3. Repeat the steps above to add
   “domino” as another game to the “games” list.

4. Your Editor should look like this
   now.

This XML support in JBoss Tools allows me to easily wire my components together (like Spring, though Spring IDE can’t compare) and still get all the ooze of Seam. So why wouldn’t I fall in love with XML editing with JBoss Tools. And note, JBoss Tools 3.0-alpha is out with experimental pages.xml editor, visual view of navigations, portlet and a host of other stuff that you are better of finding out for yourself. And I’ll definitely be blogging about my experiences with it very soon.

Technorati Tags: JBoss Tools, Seam, Eclipse

RichFaces plugin Released for NetBeans 6.1

< 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.

---

28th May 2008

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!

GenKey Africa Is here

o by God’s grace I was confronted with the choice of learning for an MSc in Networks and Distributed Systems and doing networks and distributed systems real hand with stuff like SOA, ESBs, Web Services, SVN etc. Well, I give it a very long thought (about 5 minutes) and decided to go for the latter. So here I am in East Legon, Accra with Diabeney Agyiri-Tetteh and Wesley Kirinya from Kenya.

GenKey Africa has started and the first week has been challenging enough already. As if that is not enough, there’s a lot of pessimism about whether we can achieve what the American, Indian and Irish software developers can achieve. Suffice it to say that with my boss Hajo Birthelmer guiding us, and even more importantly with God on our side, we’ll beat everyone’s expectations.

So I now have to get comfortable with something called Spring (why does that give me the chills). Being a proponent for standards in enterprise Java, I thought Seam and Google Guice’s Web Beans JSR gave me enough motivation to stick with Seam as my preferred dependency injection-based framework.

Then to make it worse I also have to get comfortable with Eclipse. I’ve always had a bias against it and it SWT leanings, but because Spring support in Eclipse is quite advanced, i guess there’s no other choice. I might as well enjoy learnig and using them as I go along.

I’m already missing the folks on campus I used to teach and discuss Java and Linux technologies. Hope to spend sometime with some of them when they are on vacation. Like to say a few thanks though to Frank Appiah, Edwin Amoakwah, Appiah-Kubi, Nana Sawyer, Julius Kudjoe, Annan Sowah, Boamah Steven and Tolu Erinle. Keep up the hard work.

To my Seam friends, don’t worry we still have a long way to go yet. Keep your eyes on the ball.

To all the folks that turned up for my seminar on Seam, thanks for coming and I hope you enjoyed the session. Hope to do another seminar sometime soon and you’re definitely on my list.

Accra Seam Seminar Update

In my haste to announce the seminar I forgot to add the time. Its between 3:30pm and and 5:00pm. Date again is 24th April at AITI-KACE, Accra.

See ya there.

Seam PDF Rendering and JPA Native Queries

< Seam Portlet Bridge … | RichFaces Plugin Released >

One of the reasons why I’ve come to love Seam is that it really lives up to its appellation as a programming and integration model – because of its ability to let me use technologies which are complex in their own right without the need to learn the nitty gritty of them. One example is the use of facelets for email, something which if I had to do programmatically using the JavaMail API will be quite a hell. With Seam all I have to learn are new facelets tags related to email. I still have access to my Business Process, Application, Session,Conversation etc contexts and can use resources from these contexts just like a normal facelet which generates a web page. Another one is pdf rendering, and that is what we’ll be talking of today.

I’ll use the shopper application that I developed for my previous post on AJAX, DataTables and Seam. Before we go on though, let’s not forget to mention the need for the following jar files in your classpath as per Chapter 16 of the Seam reference manual.

• itex.jar

• jboss-seam-pdf.jar

Next add these declarations to your web.xml file

<servlet>

        <servlet-name>Document Store Servlet</servlet-name>

        <servlet-class>org.jboss.seam.pdf.DocumentStoreServlet</servlet-class>

    </servlet>

    <servlet-mapping>

        <servlet-name>Document Store Servlet</servlet-name>

        <url-pattern>*.pdf</url-pattern>

    </servlet-mapping>

And these to your components.xml file, making sure the namespace is properly declared

<pdf:document-store use-extensions="true" />

Since we will be using charting from JFreeChart, we need to add these additional jars.

•  jcommon.jar

•  jfreechart.jar

I’ve decided to add two links that render pdf documents. One provides a pie chart of the products held in my database and their stock levels. Very simple use case, since all I have to do is to select the products I’m interested in into an ArrayList and display them.

public List<Product> getProductView(){

return entityManager.createQuery("Select p from Product p").getResultList();

}

Here is the section of the facelet that displays the contents of the resulting ArrayList.

    <p:image alignment="right" wrap="true" value="/jboss.jpg" />

    <p:font id="test" size="24"><p:paragraph spacingAfter="50">Chart</p:paragraph></p:font>

    <p:piechart title="Product Stock Levels" width="500" height="350" legend="true" is3D="true" plotForegroundAlpha=".25">

    <ui:repeat value="#{shopList.productView}" var="item">

          <p:data key="#{item.name}" value="#{item.stock}" />

    </ui:repeat>

    </p:piechart>

Now that the easy one is out of the way, lets look at the second link. This is to render a table telling us the date a cart was created, the total cost and the number of products in that cart. Well, date and cost fields are already declared on the Cart entity we created and we could do cart.getCartItems().size and get the number of products in each cart. But I decided to use a less talked about feature of JPA – native queries. Native queries enable us write SQL statements to retrieve records in our database that may not have been captured, modelled or contained in an existing entity. These allow us to write very complex queries and apply aggregation functions and so on on data.

We begin by first examining our query

select cart.date_created as date,cart.cost as cost, count(cart_item.product_id) as products from cart left join cart_item on cart_item.cart_id=cart.id group by date

Hmm. We have three aliases/fields being fetched from the database. JPA requires the declaration of an @SqlResultSetMapping which assigns a name to a native query and the fields that will be fetched from that native query. I decided to declare mine on the Cart entity, though I could have declared it on any entity.

@SqlResultSetMappings({

    @SqlResultSetMapping(

    name = "productStock",

            columns = {

        @ColumnResult(name = "date"),

        @ColumnResult(name = "cost"),

        @ColumnResult(name = "products")

    })}

Having sorted out what I want to fetch and meeting JPA’s requirements on declaring a @SqlResultSetMapping, I now go on to fetch the data using the entityManager.

public List<Map> getCartView(){

        List<Object[]> results = entityManager.createNativeQuery(

"select cart.date_created as date,cart.cost as cost, count(cart_item.product_id) as products from cart left join cart_item on cart_item.cart_id=cart.id group by date","productStock").getResultList();

List data = new ArrayList<HashMap>();

        if (!results.isEmpty()) {

            for (Object[] result : results) {

                HashMap resultMap = new HashMap();

                resultMap.put("date", (Date)result[0]);

                resultMap.put("cost", result[1]);

                resultMap.put("products", result[2]);

                data.add(resultMap);

}

        }

return data;

}

There are lot of things to note here.

1. We use entityManager.createNativeQuery(), not entityManager.createQuery().

2. After stating the query, you must also give the name of the named query which you defined in the SqlResutSetMapping. Ours is “productStock”.

3. Each row/record of data fetched from the database is assigned to an Object array. In this case “date” is in the 0^th index, “cost” is in the 1^st and so on. Since I’m fetching more than one, I use entityManager.getResultSet() and assign to a List.

Expression Language( EL) allows us to refer to data in a Map by its key, and that feels more natural to me on my facelet than referring to indexes of an array, so I rather iterate through my “results” List, creating a HashMap for each row/record from the database and using appropriate names to refer to the fetched data.

Now here’s the facelet that renders the table containing our records.

  <p:image alignment="right" wrap="true" value="/jboss.jpg" />

  <p:font id="test" size="24"><p:paragraph spacingAfter="50">Table</p:paragraph></p:font>

  <p:table  columns="3" headerRows="1">

  <p:cell ><p:paragraph alignment="center">Date</p:paragraph></p:cell>

  <p:cell><p:paragraph>Cost</p:paragraph></p:cell>

  <p:cell><p:paragraph>No. of products</p:paragraph></p:cell>

  <ui:repeat value="#{shopList.cartView}" var="data">

   <p:cell><p:paragraph><p:text  value="#{data.date}"><f:convertDateTime dateStyle="medium" type="both"/>

</p:text></p:paragraph></p:cell>

<p:cell><p:paragraph>#{data.cost}</p:paragraph></p:cell>

<p:cell><p:paragraph>#{data.products}</p:paragraph></p:cell>

</ui:repeat>

    </p:table>

Explaining each of the individual tags on this facelet is out of the coverage area of this post and further details can be gleaned from the Seam Reference Manual. However using EL, I can just refer to the date field as #{data.date} and so on and we will all be none the wiser. Of particular interest is the use of the <p:text/> tag. It allows us to apply JSF formatting/conversion etc on data being rendered in a PDF, and here we needed to format the date using the f:convertDateTime. Another use of this is to determine if some data will be rendered using the standard “rendered” JSF component attribute.

The combination of bijection and contexts means that Seam can always find whatever I’m referencing in its appropriate context and display it for me, whether on a facelets web page, PDF, email or in an asynchronous process.

---

Added on 7th April 2008

Give the code a spin and see.

Seam Seminar at Kofi-Annan Centre, Accra

As part of efforts to create a greater awareness of enterprise java technologies and tools especially on JBoss Seam, I’ve been able to secure a seminar on the 24th April 2008 at the Kofi Annan Center (AITI-KACE), Accra Ghana. This is part of their Technology Transformation Seminar that they organise to talk about trends and technologies in IT.

The seminar is titled “Stateful, Secure Enterprise Applications with JBoss Seam” and as the title suggests will be centered on the use of the Seam framework in web-based enterprise application development.

Looking forward to meeting all interested “Seamers” there. Will make the slides available on this blog after the seminar. Thanks in advance to AITI-KACE for the opportunity.

My next post will be focusing on PDF report generation and subsequently a look at the new feature of natural conversations. Keep your eyes on the ball.

Seam JBoss Portlet Bridge Realeased

< AJAX Magic with DataTables | Seam PDF Rendering … >

I was glad last week when I heard that the JBoss Portlet Bridge has been released for deploying Seam projects in JBoss Portal.

I’ve been waiting for this for a while, since I find the idea of portals very interesting. I evaluated the SeamBookingPortlet example that comes with this release and its not bad. Looking forward to the opportunity to develop applications for a business in a portlet fashion, and will be blogging on my portlet learning experiences.

The last milestone I’m waiting for is the ability to deploy JBoss Portal on Tomcat, a feature which can only be available after the completion of the JBoss 5 project which includes the new JBoss Microcontainer. This feature will enable JBoss apps like JBoss Portal to be deployed on Tomcat.

JBoss, speed it up.

AJAX Magic With JSF DataTables in Seam 2.0

<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.