David R. Heffelfinger

One of the features I really liked about NetBeans was it's Visual Web Pack (VWP) functionality, it allowed developing the GUI of a JSF application by simply dragging and dropping components from a palette into the page.

Although I have no trouble actually typing code or markup by hand, especially with a  good code editor such as the one provided by NetBeans, the convenience of VWP didn't stop with the visual drag and drop.

When creating a VWP page, a managed bean was created automatically, and automatically added to faces-config.xml. Although on the surface this sounds simple, it was a big time saver. Additionally, a database table could be dragged to some of the components, and a lot of "plumbing" code was automatically generated to display or update, as illustrated in this tutorial.

Visual Web Pack used the Woodstock JSF component library, in October 2008, Sun announced that it would be abandoning project Woodstock, but luckily provided a migration path to IceFaces, going as far as having IceFaces provide a VWP plugin for NetBeans. Unfortunately it looked like this was the beginning of the end of VWP.

I actually used the IceFaces VWP NetBeans plugin for a small project, although my initial impression of the NetBeans IceFaces plugin was less than favorable, after a while I started liking it. Lately, I've been using the NetBeans 6.7 release candidate, one of the first things I did after installing this version of NetBeans was to get the IceFaces NetBeans plugin for it. To my surprise and dismay, it does not provide Visual Web functionality.

It is really unfortunate that for whatever reason, IceFaces decided to drop support for visual web development, as far as I can tell, all their current NetBeans plugin does is provide a palette that introduces markup to JSF pages (mind you, this is not visual), and include the IceFaces libraries in any JSF project declared to use IceFaces.

Dragging and dropping into markup is not really that useful, we can simply type an opening angled bracket ("<") and hit ctrl+space to see all the JSF tags we can use, this is actually faster than moving the hand to the mouse, scroll the components in the palette up and down until we find the one we need, then drag it and drop it to the appropriate location on the page.

The one thing I will miss the most is the automated managed bean generation, in practice, I rarely used the feature where a database table could be visually linked to a JSF component since th generated code was a bit convoluted an unusual. I want to say it used JDBC, but this is not exactly accurate, it used a VWP specific concept of a dataprovider to link the database data to the component, I tend to use JPA in my Java EE projects, the fact that the database table drag and drop functionality did not generate JPA code kept me from using it in my project.

In any case, it looks like VWP is dead, long live VWP!

Recently I will start working on a project using Wicket. I used Wicket briefly in the past, I wrote an article about it and even worked as a technical reviewer for a book on Wicket, but I have never used it in production systems.

On the other hand, I have written two books that cover JSF, I also teach a class that covers JSF development, and I have worked on some projects that use JSF in production. As the author of two books that cover JSF, I have a vested interest in having JSF remain popular, therefore I am obviously somewhat biased, however I'll try to be as objective as possible when making this comparison.

All of my Wicket experience happened a few years ago, I haven't used it much in about three years, so for the past few days I've been refamiliarizing myself with this framework.

When comparing Wicket with plain vanilla JSF wicket is the clear winner. The fact that the markup in Wicket is plain HTML (with special wicket specific attributes) makes Wicket much more accessible, since no special knowledge of Wicket components is needed to come up with the markup. This allows web designers to do what they do best, design their user interfaces with their preferred tools such as Dreamweaver or other web design tools. The changes to the markup to make it work with Wicket are minimal, the wicket specific attributes need to be added to HTML tags that will be replaced at runtime with Wicket components. However, very few people use "vanilla" JSF. Most JSF developers use a component library such as ICEFaces or RichFaces. Furthermore, Facelets is a very popular view technology that can also use standard XHTML to develop JSF views. When component libraries and Facelets enter the picture, picking a winner is not so easy.

The fact that Wicket uses standard HTML for its markup may be an advantage or a disadvantage depending on your situation. If you are working with a professional web designer, then having straight HTML as markup is a real advantage. However, if your team consists primary of Java developers with little or no web design skills, then using a JSF component library that renders its pages using predefined CSS and Javascript, then in this case JSF may have the advantage.

Wicket reminds me a lot of working with Facelets, when using Facelets, we can develop pages that are plain XHTML, however we are not prohibited from using JSF specific tags. When previewing a Facelets page in the browser, the JSF specific tags are simply ignored.

Wicket also has some Wicket specific tags, however they are used to ignore parts of the HTML when it is rendered in the browser and other functionality, they are not really meant to be rendered. On the other hand, HTML tags in Wicket can have an wicket id corresponding to a component that renders HTML on the page, for example, a <span> tag could map to a custom Wicket component, therefore, a Wicket page may not preview exactly like it will be rendered when the application is deployed, which is the case with Facelets as well.

My impression on which one is better is, like in most cases, it depends. If a professional web designer is available, then Wicket may be the better choice, however if most of the development team are backend Java developers, then using JSF with Facelets plus a component library such as IceFaces or RichFaces may be a better choice.