RichFaces media output. Why not? Here is why.

So, few words about RichFaces. You know the general details, of course, and I'm sure Google is of more help than I am on that and many other matters. From my experience, it is very usable, easy to start with, with nice skinning mechanism and very usable default skins (unlike IceFaces, for instance). Since ADF is proprietary framework (and good luck with finding anyone willing to pay license for it), it only makes sense comparing it to IceFaces. It is more stable, has quite larger community (I didn't count, but searching for problems and answers on the web was pretty easier for RichFaces). As everything else, both IceFaces and RichFaces have a few quirks, and noting them all would take some time, so I have chosen the one that gave us the most trouble.

RichFaces mediaOutput component, as you can see in live demo, can be useful for displaying various media content you generate, as said on the linked page, "on the fly". Sure, it worked quite well in the demo, but once we started using it in our application, it turned out to be quite a burden.

I noticed something was wrong when I tested it in Internet Explorer. The damn browser still holds quite a bit of a market, although competition is numerous and, in my opinion, better. Firefox is my default browser for about five years, and I am satisfied with it, although since my recent purchase of a Macbook, Safari became my primary browser (I simply like the cover flow stuff) although Firefox is still used from time to time and is a default system browser (mostly for my home projects). But using Firefox in a corporate environment is still novelty new in my country, and some companies simply have company standards which require MS technologies, including IE (even in version 6.0!). So, you simply can't avoid browser compatibility.

Browser compatibility hurts like hell. CSS stuff has always been a challenge for browser compatibility and things didn't get better with xFaces frameworks. Because of their relying on a bundle of styles and JavaScript, it is a very sensitive matter. You will often have a very nice working page in Firefox, Chrome and even Opera, but in IE it will cause a number of errors, usually indicated only by message in lower left corner. When you open that message, you will see something saying that there is an error in ".../a4jsf/93hjd90u39j93e3e/homeiu384.js", somewhre deep in RichFaces source. Of course, other browsers can also cause similar problems, but on our project, it turned out that IE is the biggest problem, at least for working with components from RichFaces.

We had a need for pop-up window which displays contents of remote HTML or PDF files. Pop-ups in RichFaces are implemented as panels which are shown/idden using JavaScript (wrapped up in RichFaces whith convinient show() and hide() functions, as you can see in the examples). We followed the examples from livedemo website, and soon had nice working example of MediaOutput in Firefox, Chrome and Opera. Unfortunately, IE simply showed blank window. Google, RichFaces forums, Ilya and everything else didn't give any other aswer than "It works in our examples in livedemo". Sure, if our applications were that simple as demos. Don't get me wrong, your own messed up forms and can cause trouble which some browser can tolerate, and some can not. For instance, thanks to templates, includes and our carelessness, we had a case of nested forms (a big no-no), which was tolerated by Firefox, but Chrome just stopped rendering a page and showed error output. So it would be wrong to blame framework and RichFaces developers (who have done quite a job) for everything that has gone wrong. But in this case, MediaOutput did not work in IE.

We have lost quite a lot of time and finally implemented our functionality using simple HTML OBJECT. Works everywhere. In fact, RichFaces eventually transforms your mediaOutput component into OBJECT so the result is the same, only RichFaces gets sometimes lost in the way.

I still recommend RichFaces for JSF frameworks. It is good, nice looking, but it is nice to know it's limitations. But the only way to get to that is by painful experience. But that is our job. My motto, which is popular children song sang during kids games, describes our programming work: "Kolariću, paniću, pletemo se samiću, sami sebe zaplićemo, sami sebe rasplićemo...". The bold part, in Serbian, says:"we tangle ourselves, we untangle ourselves". I think you get it :)

P.S.

As for ADF, well, it has taken a few years of my life, been a good experience... I wonder if I will be using it again. It is browser-safe, obviously well tested, pricey, and, taken in account ADF bindings and data controls, good only if you have well defined and stable architecture underneath (yeah, business components).

Difference in comparin Integer between JDK 1.6.0_11 and JDK 1.6.0_18

Quite busy summer, but just to post quick info about thing that happened to me a moment ago.

I develop application on a Windows machine, test it etc. and once a day I deploy it to our Linux server for our testers. You know those situations "App works perfectly on my machine, but crashes in production"? Well, after checking parameters and other config stuff, I turned myself to my Log4j trace (yeah, should have done that first) and it turned out that certain validation of mine fails.
It compares two Integer values, in this example 37 and 37, by using != operator.

So, machine A, JDK 1.6.0_18, a == b returns true
Machine B, JDK 1.6.0_11 a==b returns false.

where a and b are Integer(37).

Safe way, of course, is using equals method, or comparing by intValue property.

A lot of interesting stuff about RichFaces in my project has happened this summer, but I leave that for some other time. Deadlines and stuff, you know :)