Blogging about ICEfaces

One of my favorite software development frameworks - ICEsoft's ICEfaces started a blogging contest (one of the prices is an iPad - nice since my fiancee probably won't approve the budget for a gadget like this).

What I really like about ICEfaces (in comparison to trinidad, what we've used before):

• Nice looking components (probably not the most important one from a development point of view, but hey, that's what sells the products and thus pays my salary :-))
• Active and Helpful forum (http://www.icefaces.org/JForum/search/filters.page). This cannot be valued too high - in my opinion. I'd say roughly 70% of my questions could be answered by searching in the forum and checking the answers people with similar problems had - the other useful source is the public ICEfaces JIRA
• Consistent attribute naming
  Trust me, this is really a big improvement comparing it with something like trinidad. When the attributes all are named consistently it is very easy to exchange components (replace a dataTable with an panelPositioned or a panelSeries for example, switching between inputText and outputText etc.)
  
• Awesome features that come out-of-the-box
  - Push Server
  - Drag and Drop
  - and all the other nice things that can be seen in the component showcase
  

So, you can expect quite some posts about it and of course also my unfiltered opinion.

I'd like to kick it off with my first impressions after having looked at the (fairly new) composite component suite (http://composite-component-showcase.icefaces.org/icefaces-composite-comps-showcase/showcase.iface):
We just recently got access to it (licensewise) and this will really save us some time in future development. The new tables, dual lists and layout components look especially helpful for our current project. I'm really looking forward to using them as soon as possible.
In the past we've implemented something like filterable column headers on our own - we've got a working blueprint for this now, but it requires quite some knowledge about the surrounding program logic to get it successfully integrated in a complex screen.
Dual list won't save too much time (given, that you can also use two single lists and some backing bean data storing and controller methods) - but I'm always a big fan of writing fewer code.
The layout components will definetely play a big role concerning the sexy-factor of our application - and it is always nice to have a better looking UI for low costs ;-)

So, that's it for now - more will come quite soon.

Java Server Faces and added complexity

Having worked lately on an extremely generic component for one of our JSF (ICEfaces) based products I must really say: You have to jump through a lot of hoops because some useful functionality is missing in JSF. This list is not meant to be complete. It's just what came into my mind today:

• No parameters for method bindings
• Insufficient enum support
• Constructors for Pojos
• Dynamic method/value bindings using the Expression Language
  

No parameters for method bindings
I really think this is the worst one - anyone who ever tried to call an action with a parameter came across this issue and used one of the workarounds to actually get it done:

1. Create an additional parameter object and work with f:setPropertyActionListener (only works for actions and not for parametrized getters)
2. Use the Map-Hack: Create a Bean that implements the map interface and put all your fancy business logic in the get method - you can call the get method with one parameter (usually the key for the entry you want to access). I must admit I have used this once or twice and it gets the job done - needless to say that it's bad design and I've even read a couple of times that it has some pitfalls (that I haven't encountered so far).
3. Create a map property on your backing bean: I actually think this is the only valid approach (ok, the parameter object is fine for actions as well) if you need to access data in a parameterized way. Your parameters become the key(s) for the map property and the object you're needing is the value. This has the only downside that you have to initialize the whole content of the backing bean's map when the data is displayed to the user - whether it is really needed or not because you can't control the calling of the getter from the backing bean.

Insufficient enum support
So maybe I'm wrong on this one but I couldn't find a simple way to use enum instances in JSF pages. I couldn't create instances of an enum "on-the-fly" to access certain data or provide it as a parameter. Here are two ways to handle that:

• Completely abstract from enums in your pages and use String data fields instead (You would then have to transform the String objects into Enum constants on demand)
• Use a utility bean in that populates Map members on startup with all the elements of your enum. You can then easily get the enum instances by using the members fo this bean with ['enumInstanceName'] to actually get the objects you want right from the start

Constructors for POJOs
Say you want to provide not just a simple parameter/value to your backing bean but already an object (to limit the number of properties for your backing bean) - I didn't find a way to initialize an object from a JSF page and fill some properties. There is some sort of workaround with providing a dummy managed bean for this - the JSF framework takes care of initializing it when you access it for the first time - but it was really a drag. I tried to use this with a request scoped bean - but it kept the value during partial page submits (because for JSF a request ends only when you leave the page - it spans over different partial page submits). So I needed to cleanup the request scoped bean after having retrieved the data. I didn't really find a solution for this and sticked to using multiple properties in my backing bean.

Dynamic method/value bindings using the Expression Language
What I mean by this is: Let's say you have a bean 'A' with the String properties 'a' and 'b'. It is now not possible to use one input text component and link it to either one of them depending on a boolean value (e.g.: #{not empty bean.c ? bean.a : bean.b}). The only way to achieve this is to duplicate the text component and use the rendered flag or create a dynamic value expression in your backing bean and set it on the component programmatically.