JavaServer Faces (JSF) is the upcoming standard for the presentation layer of enterprise architectures. It’s going to replace the good old Struts. Struts, being the first widely accepted MVC 2 framework, to separate presentation from business logic, JSF now adds a real component model, event handling, validation and more to it. JSF can be compared to GUI development, although it doesn’t result in a single standalone client-side application, but in a bunch of code for the app server that delivers markup to client devices.
If you’re experienced with GUI design, using e.g. VB or Delphi in the past, you recognize that the comparison between JSF and traditional GUI design must be a joke of the marketing guys. Well, maybe the lack of professionalism in todays JSF designer tools cause this problem. From the decision makers point of view the underlying technology shouldn’t make any difference. Maybe we would expect this, but it’s still a young market segment in Java world, and reality is something different.
Very nice, we get a JCP standard. But, there are also a lot of implementations, different in quality, flexibility and use. Important components, that GUI designers take for granted, are not standardized. So, every implementation has it’s own ideas and lacks of functionality and portability in the end. So, we have to choose the best framework and keep it (like we did it with Struts in the past ;-)). Maybe components from different implementations can be mixed here and there. But, if you use all this modern stuff, like AJAX and skinning, this is not a good idea at the moment. A lot of stuff is in movement and standardization is missing at all.
The Apache MyFaces project seems to become the JSF frameworks reservoir. One day this could become the one big mama implementation for JSF development. The Apache guys already think about framework consolidation. But, this could take years, if you’ve a look at the postings in the mailing list. A lot of people still fight with basic questions, because the implementations are bad documented, not intuitive in use and miss important and expected functionality.
If you keep in mind that Sun started in 2003 to talk about the JSF specification in the public, we hear and talk about JSF for three years now. If I have a look at the results, I’m a bit disappointed. This is comparable to the Swing development and the missing practical GUI designers (for years). I’ve to repeat myself here:
Dear IDE developers, have a look at Delphi 3 from the mid 90ties and do what they did.
If we had something similar the underlying technology wouldn’t make any difference. JDeveloper, Exadel Studio and myEclipse are on the way, but unfortunately that’s still not the same RAD support Delphi offered already 10 years ago. Although, Sun Java Studio Creator, at a first glance, may seem to be the most comparable to my “Delphi postulation”, my experiences differ. I started JSF development with it, and it can be a help to get a grasp for JSF. But, if you don’t wanna follow the Sun way (JSF RI) it is a dead end. The IDE mimic is Delphi-like, but handmade here and handmade there plus the narrow corridor into JSF land, let me gave up. Not to mention, instabilities and the old Netbeans ground, that makes you crazy if you developed with Eclipse before (Eclipse vs. Netbeans).
So, what’s important, to sum up all this? You’ve to have a deep look at the JSF frameworks you’ll use and the tools support for them. There are a lot of good ideas, but not everything can be combined. Experiences show, that none of the IDEs support useful framework combinations, so that you can visually design a prototype in hours. If you think about database data visualization in JSF table components, e.g., a common request in enterprise business, the most stuff is done by hand. Does somebody remember how easy it was to create a master-detail presentation in Delphi (in minutes!).
Maybe Freddy K. is living in Trinidad
And now to something completely different. Not really, only some thoughts about the first personal nightmares with Apache Trinidad. Trinidad is the OpenSource variant of the Oracle ADF Faces. It’s the most advanced JSF implementation you can get in source code. Maybe this is true for ADF Faces in shrink-wrapped software, too. Although, there’s no official release from Apache at the moment, we use it in a project. That’s pretty leading-edge, but we’ve to pay for it.
So, where are the tweaks, you may ask. Can we or should we use it in our project, too? If you think about a shift from Struts to JSF standard it’s a good idea to think about ADF Faces or its OpenSource counterpart Trinidad. Although, Trinidad is a fork of the ADF Faces you have to expect that they soon will differ so much that we talk about different guys, that may have the same mimic, but a different engine inside.
There are plans that Trinidad will become the base for ADF Faces. But, no schedule is published. So, you’ve to decide if you wanna walk along the shrink-wrapped or the OpenSource way at the moment.
ADF Faces are an important part of the JDeveloper tools environment and the concept of modern database-driven development, like Oracle it defines. So, you can expect tools quality and support you can order for cash. As Trinidad is only a subset we have to wait a year or two until Trinidad has added what’s useful in ADF Faces and can be used today. If your project is Oracle-centered anyway, ADF Faces are the better choice.
For all of us who try to be independent Trinidad is the better solution. Trinidad is soon becoming an Apache project (at the moment it resides in the incubator ;-)). So, from the license point of view you get a brilliant source code base. You can even take the code to distribute your own Trinidad implementation if you like.
But, documentation is rare and inconsistent. The ongoing changes may follow a concept. But, you get no details about it yet. You can recognize that important parts of the implementation are redesigned, not always like you may expect it, or traceable in the end. So, it’s a bit like Indiana Jones searching for the Holy Grail. You know it is there, but you don’t really know where to search for it, first. A lot of bugs are really annoying and can cost days.
The incubator mailing list is a valuable source, because the core developers post there. Some blogs of Oracle employees writing about ADF development can help, too.
The MyFaces wiki delivers information about changes between ADF Faces source and the current Trinidad source. Although, the most documentation is a bad copy of what you can find at the Oracle site for ADF. So, at the moment you’ve to switch between both documentation sources and map by hand. The namespace and tags have changed their names (not always to get a better one), tag attributes and facets are missing or added and a bunch of internal Java classes was already edited.
If the implementation were complete and nearly bug free, the result would be no problem. But, the mapping between Trinidad CSS classes (they also call these selectors) and the Trinidad tags is undocumented. The hierarchy that allows to set global and more fine-grained skin presentations is intransparent. Try and error and a lot of deployments are necessary to find out what you have to do to get other fonts, colors, etc.
Best of all, still after this bunch of work you’re left with presentation tweaks you can’t get rid of without implementing a renderer on your own. Even better, some of the Trinidad tags have no mapped CSS class at all. This month a new release opened the skinning a bit to get a real separation between your own CSS classes, you can only use for your own presentation objects, and the Trinidad skinning classes that are only usable with the Trinidad tags.
It’s really crazy how much time you have to invest to get something changed, you would do in minutes with a HTML editor, and even get not what you tried to achieve in the end.
Besides the mentioned tweaks, we could integrate Trinidad into a Spring/Acegi Security context. We can use pure Spring beans as backing beans and work on a generic table implementation to link the presentation to a Hibernate DAO layer with semi-automated creation of transport objects that are delivered through a J2EE-like facade. The Facelets templating helps us to keep the overview of the tags we need for this.