Charts in JSF: OpenFaces, PrimeFaces and JSFLot

I’ve been playing around with a small application that needs to display results of data collection in a chart as a certain selection is made on the jsf page. So I set myself the task of looking around for libraries that could provide me this charting support. One of the important considerations was that this library had to be compatible with Richfaces, since that was my default jsf library until further notice. It was a pity though that Richfaces didn’t have one, because most of their components seem to be fully fleshed, and I don’t tend to need other components libraries unless they don’t have it.

Primefaces

I’d already heard and read about Primefaces, and the reviews were quite positive. It comes with quite an impressive set of components, and will definitely fill in the holes that Richfaces has left quite nicely, with all the cool items like Accordions, Carousels, Docks (for MacOS fans), an IdleMonitor, ImageCropper and the rest. The documentation was also quite detailed from PDF and html docs as well from forums, so I was bound to have a good time, or so I hoped. I “mavened” it and configured it alongside Richfaces, without any complaint. So, to the hacking went on. The chart components were quite may and as cool as Primefaces always tends to be, and it’s model was quite easy to work with. All I needed was to create a Map<String,Integer> containing text and data points for a pie chart. For my needs, which is a bar char, all that was needed was something like the ff from their own documentation:

public class BirthDisplayBean {

private List<Birth> births;

public ChartBean() {

births = new ArrayList<Birth>();

births.add(new Birth(2004, 120, 52));

births.add(new Birth(2005, 100, 60));

births.add(new Birth(2006, 44, 110));

births.add(new Birth(2007, 150, 135));

births.add(new Birth(2008, 125, 120));

}

public List<Birth> getBirths() {

return births;

}

}

and then on the page

<p:lineChart value="#{chartBean.births}" var="birth" xfield="#{birth.year}">

<p:chartSeries label="Boys" value="#{birth.boys}" />

<p:chartSeries label="Girls" value="#{birth.girls}" />

</p:lineChart>

Sweet! Simply using my own model and basic collections, I had my data all ready to go.

Just when I was getting ready to enjoy splattering my pages with charts all over, I came across a problem. The number of points on which data is collected in my application is flexible, therefore I do not know before hand the number of “series” that I have to display. Unfortunately, Primefaces assumes that I know them before hand, in which case all I needed was to specify each p:chartSeries with label and value. Oops, spanner in the works!! I tried to use a ui:repeat to force it to render a dynamic number of p:chartSeries, but that didn’t work. So, my honeymoon with Primefaces charts was ended abruptly. But Primefaces is still in my web application classpath, waiting for the next interesting component I might think of using which Richfaces does not have. I suspect that will definitely be sooner than later. Primefaces is way too cool to ignore.

JSFLot

My next search threw up an interesting result: JSFLot. It’s quite an interesting libray only focusing on charting, and relying mostly on JavaScript to render the chart and it’s content. It has support for pie, bar, and line charts, which would meet most application needs. It seemed not to have as yet a big community around it like the others, but it’s documentation was good enough to focus on what it does best – charting. I only wished there was a downloadable version of the documentation, so I could take my time with it at home when I’m offline. In the end I had to use Scrapbook to grab a few pages, but that was good enough. It indeed has a very small footprint, with a jar around 245k. It had it’s own datamodel that you had to stuff your results to display in, so in that sense it is intrusive on your codebase. However they are quite simple and intuitive. They are XYDataPoint (for x and y data points) , XYDataList (for a series of x and y data points, as well as other information concerning the series) and XYDataSetCollection (an aggregation of 1 or more series or XYDataLists). But nowadays, what other JSF component library doesn’t call for some small intrusion to get you going?

I began digging into it, and was getting some interesting results. The charts were quite clean and easy to label. But when I wanted to be a bit more dynamic and display different charts based on different selections from a Seam DataModelSelection, I noticed that it didn’t seem to refresh to show the changing data points from the different objects from which the data points were being displayed. I thought maybe it had to work only with full page refreshes, so I resorted to using the normal <h:commandLink/> to make sure that the whole page was refreshing and not doing any funky Richfaces ajax thingy. But no go. Seeing as I was spending too much time trying out all my Seam hacking skills, I rather decided to focus my energies on finding a different library that could fulfil my needs. Maybe I was being dumb and making some mistake somewhere, but time wasn’t on my side.

OpenFaces

Having had two heartbreaks, I went back to looking for a new JSF library love that could fulfil my need for dynamic series data, and interestingly 2 weeks ago TheServerSide had an article about OpenFaces. Hmm, not heard of them; let’s see what they’ve got. It turns out that they weren’t that bad after all. Documentation was in an html which comes bundled with the library download, and contains everything you need to know to use it. They had quite a sweet implementation of DataTable, and their implementation of sorting via headers of the columns was far cleaner and more “pimped up” than Richfaces Datatable, so I’ve switched my pages to use theirs, and I’m loving it. They also have a TreeTable, a cool way of using a table to display hierarchical structures, and a DayTable for showing scheduled events. All this and it sat quite well with Seam and Richfaces.

Here they had support for pie, bar and line charts, which though less than Primefaces’s plethora of charts, is more than enough for most purposes. Oh by the way, they could do dynamic series data quite well. All would have been rosy, except for the fact that I have to use their model to squeeze my data in. Well, it involved using 2 of OpenFaces model classes to contain my data, and coming from JSFLot’s 3 and from all the disappointments, I definitely could live with that. So like Primefaces, I could define my data points in a Map<String,Integer> structure, but unlike it, I’d put them in a PlainSeries, and then put all my PlainSeries in a PlainModel. Job done, we can all go have a beer now.

But then what will software development be like if you had technologies which thought of the developer’s every need and did them even before he could think he needed them? That will be utopia, but then I’m still on this earth. I realised that I couldn’t specify a color per data element, again because the number of data points I have to display is dynamic. I tried to use a property that will generate a random comma separated list of colours for each data point as a string property , but the tag could not resolve EL when it came to reading the “colors” property. In the end I had to hard code one colour for every element to save me from disgrace.

<o:barChartView labelsVisible="true" valueAxisLabel="No. of respondents" keyAxisLabel="Responses" colors="#800000"/>.

In fact, neither could the valueAxisLabel and the keyAxisLabel read from my locale files to determine the right text to show there. Who in this day and age still hard codes labels, when there is something call internationalization? OpenFaces, sit up!!! This is JSF, and here EL is king, not hardcoded text values.

In the meantime, I don’t have a choice. At least OpenFaces meets the real important requirement of showing charts from content which is dynamic and ajax driven. I hope OpenFaces will wake up and realise that their new lover requires some additional pampering, but I guess for now the relationship seems to be working. Who knows, if they do get better at the EL stuff, I just might actually consider moving from a relationship to a marriage.

One thing I’ve taken away from the experience though – JSF has come a long way, for me to be able to have Richfaces, Primefaces and OpenFaces in one application. And my application is not even JSF 2, where the vendors are supposed to have worked on better integration paths for the component libraries. I’m waiting for Seam 3 to be fully released, and then I’ll switch everything to CDI, JPA2 and JSF2 without sacrificing any of my PDFing, Excel-ling, SMPCing (Managed Persistence Context) and the like.

Book Review: Packt’s JBoss Richfaces 3.3

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.

For more information about the book, visit: http://www.packtpub.com/jboss-richfaces-3-3/book

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: , , , ,

Book Release : JBoss Tools 3 Developers Guide

JBoss Tools is an impressive set of open source Eclipse plugins that allow rapid development of enterprise and SOA based applications. It is developed by the JBoss group under the leadership of Max Rhydal Anderson.

It include support for rapid Hibernate, Seam, JSF and Richfaces, jBPM, JBoss ESB development and a lot more.There is no doubt that with such a compelling toolset, JBoss Tools stands out as the best set of tools for Ajax based JavaEE development that you can get for free and compares very well with those for pay.

To quickly point out how to harness the power of JBoss Tools for rapid application development, Packt Publishing has just announced their book JBoss Tools 3 Developers Guide by Anghel Leonard, scheduled to be released in April 2009. I believe this is the first book on JBoss Tools, and it has come at the right time for us developers.

Taking a hands on step by step approach to the 11 Chapters detailing each of the plugins at the time of writing, a developer is immediately delved into productive use of JBoss Tools in their project through a small project developed per chapter.

Of course, you will not expect to learn everything about Seam, Hibernate, Richfaces, JBoss-WS etc from the book simply because that is not the aim of it. However pointers are given to the right resources that will get you up to speed on them.

It has been fun being a technical reviewer of this book and I have to congratulate Leonard and the staff at Packt Publishing (Sarah and Leena) for their hardwork. I eagerly look forward to the release in April.

Don’t say I didn’t tell you how good it is, because this post is evidence that I have.

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. Scroll through the XML Catalog and
    find the key “http://jboss.com/products/seam/components-2.0.xsd”.
    Click Next.

  4. 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 2nd 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: , ,

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!