Great post about JSF

Hi there folks!

even though this blog is pretty much dead as I'm a happy Grails developer now from time to time friends keep sending me links to other blogs about JSF and its nightmares.

Today I've been given this link:

http://www.dzone.com/links/r/top_10_reasons_why_i_dont_like_jsf.html

I think the author is way to polite but he's got the main issues nicely laid out.

Good job, Bruno!

This is the end!

Hi all,

this is the final post on this blog. My adventure with JSF has finally come to an end. No more nonsenses, no more pain...

I'm working with Ruby on Rails and Grails now and I strongly recommend if you're not a total convert as of now to start learning those platforms ASAP. You'll see life having a new, better taste and a whole new meaning!

A big thanks to all of you who posted comments, visited my blog and linked to it. Thanks!


Rust in Peace JSF!

Custom Components strike back!

Hi all you JSF haters! Here's yet another heresy about writing JSF components you might want to know before you step into the ugly world of creation of reusable parts.

First of all if there's someone you know that knows for a fact that writing custom components is easy please direct that person to me so we can shed some light on why he/she things so. In my opinion having a 32 pages long manual just to achieve the simplest possible result (like this one) is just plain crazy. Please note that all this component does is it can show/hide itself from the resulting HTML, it can "bind" itself to a server-side bean and has a handful of properties most of which contradict with the actual well-known attribute names from HTML (for example styleClass where the well-known name for this is simply class).

Secondly one needs to notice that beautiful picture on page 10 that shows the necessary bits and pieces to make it work. Actually it shows the "simplified" version without separate renderers!

So what we need to have is 2 classes (the so called "Tag" class and the actual "Component" class) and 2 xml files (one being a tag library descriptor and the other one being the faces-config.xml).

Oh! And btw if you're wondering if they made any progress on that one in JSF 2.0 I rush to explain that they didn't! They only switched from the tag library descriptor to Facelets descriptor which has pretty much the same content, just more catchy name!

After going through the painful, unrefactorable xml bush we're presented with the powerful class model that we need to work with.

At this stage I really need to ask this question: was it really so damn hard to implement a pass-through for arguments??? I mean, come on guys! It's like stone age compared to what's available in other frameworks.

Back to classes...

The TickerTag class begins pretty simple - a field, getter, setter,... and then - the setProperties and release methods. "setProperties - what's that" you might ask. Well my friend, the fact of having a getter and setter is just not enough to make it work! You need a separate method that again contains some non-refactorable code simply to use it in the actual component tag... It doesn't get any worse than that, really...

But anyway... Let's see how we can implement the famous binding to bean properties!

In setProperties there's an if-statement to decide if it really _is_ a binding or a value. That thing could have been done one level down and not force the component writers to do this crazy check all over the place. One might ask at this point that since we're already storing the value why not re-use that in the actual code so that we don't multiply the instance of our values (once in the backing bean and once in the actual component itself). Well - keep askin'! That's simply how things are - period.

JSF component creation is a literal pain in the a$$. The actual model is plain stupid, does not provide an easy way to do simple things and requires one to write tons of stuff, possibly wrong at first (that's when nothing works). By comparison the model for creation user controls in ASP.NET is easier because every component is just a class that inherits from some other class (UserControl to be precise) and has both parts (the composition from other controls and custom rendering) simply built in. It is so easy that if you once go ASP.NET you'll never go back (at least not to JSF).

Back to reality - meaning to JSF :)

Beyond the simple, 32 pages long tutorial there are topics that are way more complicated like processing user input or action components. If you have the guts to go there please share your experience with the rest of us because the amount of tutorials and walk-throughs out there is just not enough.

RichFaces - "beautiful" code

I'm extending the rich:calendar control today trying to put its definition into a table (for reasons that are not important here). The outcome should be as easy as input in one cell and the icon in another. Sounds easy, right?

Nothing could be further from the truth!

How I'd envision generation of HTML in such a case would be a container class having things like name, attributes collection, possibly even child controls (if it's a container for other controls) with one method "render(where...)" that would make use of those contained properties.

But it turns out that the guys from RichFaces didn't get the memo, that code duplication is bad. In fact they missed it so much that getting the whole thing to do what I want it to do takes a copy and paste, then refactoring and at the end implementation of the stuff I need.

Here's an example of how the render for example attributes of a control:

getUtils().writeAttribute(writer, "accesskey",
component.getAttributes().get("accesskey"));
getUtils().writeAttribute(writer, "class", "rich-calendar-input " +
convertToString(component.getAttributes().get("inputClass")));
getUtils().writeAttribute(writer, "disabled",
variables.getVariable("disabled"));
getUtils().writeAttribute(writer, "id",
convertToString(clientId) + "InputDate");
getUtils().writeAttribute(writer, "maxlength",
component.getAttributes().get("maxlength"));
getUtils().writeAttribute(writer, "name",
convertToString(clientId) + "InputDate");
getUtils().writeAttribute(writer, "onblur",
component.getAttributes().get("oninputblur"));
getUtils().writeAttribute(writer, "onchange",
component.getAttributes().get("oninputchange"));
getUtils().writeAttribute(writer, "onclick",
component.getAttributes().get("oninputclick"));
getUtils().writeAttribute(writer, "onfocus",
component.getAttributes().get("oninputfocus"));
getUtils().writeAttribute(writer, "onkeydown",
component.getAttributes().get("oninputkeydown"));
getUtils().writeAttribute(writer, "onkeypress",
component.getAttributes().get("oninputkeypress"));
getUtils().writeAttribute(writer, "onkeyup",
component.getAttributes().get("oninputkeyup"));
getUtils().writeAttribute(writer, "onmouseout",
component.getAttributes().get("oninputmouseout"));
getUtils().writeAttribute(writer, "onmouseover",
component.getAttributes().get("oninputmouseover"));
getUtils().writeAttribute(writer, "onselect",
component.getAttributes().get("oninputselect"));
getUtils().writeAttribute(writer, "size",
component.getAttributes().get("inputSize"));
getUtils().writeAttribute(writer, "style",
"vertical-align: middle; " + convertToString(component.getAttributes().get("inputStyle")));
getUtils().writeAttribute(writer, "tabindex",
component.getAttributes().get("tabindex"));
getUtils().writeAttribute(writer, "type",
variables.getVariable("type"));
getUtils().writeAttribute(writer, "value",
getInputValue(context, component));

I mean who does that in the 21th century in an object-oriented programming language?!?!?!?!?

Here's another example of pure madness:

writer.writeText(convertToString(
"dayListTableId: '" +
convertToString(clientId) +
"Day', \n weekNumberBarId: '" +
convertToString(clientId) +
"WeekNum', \n weekDayBarId: '" +
convertToString(clientId) +
"WeekDay',\n currentDate: " +
convertToString(getCurrentDate(context, component, currentDate)) +
", \n selectedDate: " +
convertToString(getSelectedDate(context, component)) +
", \n datePattern: '" +
convertToString(component.getDatePattern()) +
"',\n jointPoint: '" +
convertToString(component.getJointPoint()) +
"',\n direction: '" +
convertToString(component.getDirection()) +
"',\n boundaryDatesMode:'" +
convertToString(component.getBoundaryDatesMode()) +
"',\n popup: " +
convertToString(component.isPopup()) +
",\n enableManualInput: " +
convertToString(component.getAttributes().get("enableManualInput")) +
",\n showInput: " +
convertToString(component.getAttributes().get("showInput")) +
",\n disabled: " +
convertToString(component.isDisabled()) +
",\n readonly: " +
convertToString(component.getAttributes().get("readonly")) +
",\n ajaxSingle: " +
convertToString(component.getAttributes().get("ajaxSingle")) +
",\n verticalOffset:" +
convertToString(component.getVerticalOffset()) +
",\n horizontalOffset: " +
convertToString(component.getHorizontalOffset()) +
",\n style:'z-index: " +
convertToString(component.getAttributes().get("zindex")) +
"; " +
convertToString(component.getAttributes().get("style")) +
"',\n firstWeekDay: " +
convertToString(getFirstWeekDay(context, component)) +
", \n minDaysInFirstWeek: " +
convertToString(getMinDaysInFirstWeek(context, component)) +
",\n todayControlMode:'" +
convertToString(component.getAttributes().get("todayControlMode")) +
"',\n showHeader:" +
convertToString(component.getAttributes().get("showHeader")) +
",\n showFooter:" +
convertToString(component.getAttributes().get("showFooter")) +
",\n showWeeksBar:" +
convertToString(component.getAttributes().get("showWeeksBar")) +
",\n showWeekDaysBar:" +
convertToString(component.getAttributes().get("showWeekDaysBar")) +
",\n showApplyButton:" +
convertToString(component.getAttributes().get("showApplyButton")) +
",\n resetTimeOnDateSelect:" +
convertToString(component.getAttributes().get("resetTimeOnDateSelect")) +
",\n defaultTime:" +
convertToString(getPreparedDefaultTime(component))), null);


Finally please note that both fragments come from the same single method and that's just a fraction of that method!

Now you tell me: would you ever use stuff that looks like that underneath the skin?

JSF - a component framework only the mother can love

Hi there,

this is another JSF nonsense - the component creation style.

I'm just sick an tired of going over the renderers that don't render anything, the component tags (like it's not enough to have just one of those guys)... I mean come on!!!

For those of you that say that JSF 2.0 make a difference I rush to clarify that it is so not true - the component model didn't change even a bit! What they added is Facelets which is what most people were already using anyway.

What's screwd though is that Facelets is a templating engine and they try to use it for component creation. That's grouse!!!

Trinidad + Richfaces = Problem (solution)

Finally after 3 days of googling and a trial-and-error approach I've found out how to overcome the problem with links in a table being stripped from javascript code after an Ajax call (for example for pagination or sorting columns).

The answer to that is a4j:htmlCommandLink (instead of h:commandLink) inside an a4j:form (instead of h:form). Don't ask me why - it's to complex to describe the actual bits and pieces behind some sick concepts in those libraries. The final fact is that h:commandLink ain't working but the a4j:htmlCommandLink is. Period.

Later today I'll attach a working project with the solution. For now you're just going to have to trust me on that one :D

RichFaces 3.3.1 Bug

Another day got lost because of some guy trying to make things that work better. This time it's sorting of columns generated from list. All used to work until version 3.3.0.CR1 and then, all of the sudden, it stopped. You can click the damn header all you want and nothing happens.

Components involved: rich:dataTable and rich:columns

O my gosh how I hate those days...

RichFaces + Trinidad = problems

I've been fighting for over 3 days on that so you might wanna listen to the story not to make the same mistake I did.

Some time ago someone decided to use JSF libraries in our project. That same someone decided to use RichFaces (a nice library indeed) and Trinidad (the most terrible piece of code I've ever encountered) in one project.
As the story continued we've been using both of those libraries and it worked quite nice right up to the point where I wanted to use rich:datascroller on a rich:dataTable component containing some action links.

Just so that you know what I'm talking about I'm giving you 2 small projects that show the problem. One without Trinidad configuration (this one is working just fine) and the other one with Trinidad.

example-01-working.zip
example-01-not_working.zip

Basically the Ajax rendering engine from RichFaces is being crushed down with the one from Trinidad. They just hate eachother!

I've never ever expected that 2 libraries might have such a negative impact on eachother! What a waste of time!!!

JSF + HTML - a sudden divorce

Now here's a neat one: try mixing HTML and JSF markup in one place. It's all nice and dandy unless there's no html->jsf->html->jsf nesting. In that case the JSF tags are omitted! Here's an explanation why that was the case in JSF 1.1 and that it's supposedly fixed in 1.2 but I've tried it out and it's still not working.

FYI: that works just fine on multiple level of nesting in ASP.NET!

Trinidad nonsense

Today I've spent almost 6 hours trying to find out the CSS responsible for introducing an 8 pixel top margin for body. The case is even stranger in that the mysterious margin appears only in Internet Explorer. Imagine the 8px disruption in absolute positioning of the elements on the page - it just looks bad.

Finally I've found the problem: Trinidad introduces some stylesheets that do exactly that.

Well it wouldn't be much of an issue if it were not for the fact that this damn CSS is included as the last thing in the head!!! So you can do anything you like - body will always have this damn 8 pixels margin in IE only no matter what.

I'd like to find out who the butthead that invented this piece of sh** is. I mean, come on!!! Someone must have been stoned to do this kind of thing!

The worst thing is I have not damn idea how to fix it other than using some sort of on-load method to correct the CSS for body element. jQuery works well, but this is the ugliest hack I've ever come across.

JavaScript and Facelets

Did you know that you're not allowed to use the full syntax of JavaScript language with Facelets? Well, I didn't and it took me over 4 hours to find that out. Let me explain:

Here's a simple JS function that will cause the rendering engine swallow it's own tongue and spit a nasty error message:

  <script>
function doSomething(items) {
  if(items.length > 0 && items.length < 5)
    return;
}
  </script>

First of all the < and > are not valid characters in XML so they are not valid in Facelets as well. And if you substitute them by &lt; it will be rendered as &lt; which makes the usage of < character impossible.
The same situation is with > sign as well as with && operator.

Of course you might say that my doSomething function makes no sense - it's for educational purposes only!

May the spirits protect us from Facelets!

Using Maven's Apache MyFaces archetype with GlassFish v3

I've faced a simple task to create a component that will render a recursive unordered list that can be later on turned into an accordion. Nothing really fancy.

Since there's no such component that I know of to do the rendering in the way I want it to I've decided to create my own component.

Using Maven I've created a new project from MyFaces archetype available in the default Maven repository. Armed with an example application I started my work.

The shock came right after running the generated app for the first time. Here's a snippet of the jsp page:

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<html>
    <head>
        <title>Hello World</title>
    </head>
    <body>
        <f:view>
            <h:form id="mainForm">
                <h:panelGrid columns="2">
                    <h:outputLabel for="name" 
                      value="Please enter your name" />
                    <h:inputText id="name" 
                      value="#{helloWorld.name}" 
                      required="true"/>
                    <h:commandButton value="Press me" 
                      action="#{helloWorld.send}"/>
                    <h:messages showDetail="true" 
                      showSummary="false"/>
                </h:panelGrid>
            </h:form>
        </f:view>
    </body>
</html>

Using NetBeans (the only freely available IDE that makes sense for Java development) I've started GlassFish v3 and deployed my newly generated application to the server.
The "Run" option on project has opened Firefox with the right address and everything looked OK. So I thought: let's take a look at the generated Html before I start adding something to it. And that was the moment when the fun begun!

The generated HTML has the following structure:

1. Form (as a top-level element) with all the controls
2. Html with Head and Body containing some JavaScript code and nothing more.

Can someone explain to me the reason it is so difficult to produce some proper output even from the simplest application??? Is this something you'd put your money into (I mean like more than one dollar of course)?

...because it's designer friendly

Here's just one quick note that I just couldn't live without sharing.

There's an opinion that it is better to use a more declarative approach to web development (like JSF/Facelets does) because it is easier and more comfortable for the web designers to interact with the page design.

Web Designers are NOT developers! Much less JavaEE developers knowledgeable in JSF technologies. Get over it! NetBeans, Eclipse - those are Developer tools - not designers'! A designer prefers Photoshop for graphics (oh wait - there's no such thing in Eclipse, NetBeans nor in Idea like advanced image editor) and Expression Web or Dreamweaver (again, no viable counterpart in any of the IDEs).

And now for the most shocking part:

Designers don't speak JSF/Facelets nor any of the JSF frameworks like RichFaces or IceFaces. They speak HTML, CSS, possibly JavaScript too (if you're lucky!). For them a div is a div, a span is a span and a a-href is an a-href.

And I distinctly remember someone saying that it is easier to get designers to contribute to the project if you use Java Server Faces...

Ghosts in the browser

It's not a bug - it's a feature

Did you know that you're not where you are? I mean virtually of course. Confused? Read on...

Let's have a simple example: 2 simple views (or pages or however you'd like to call them). One that asks for your name and the other one that says that you're the master and this kind of things. A simple "Hello, world!" application. Nothing fancy.

Now let's assume the obvious which is: you're writing it using Java Server Faces. It's good for everything so why shouldn't it be good for a Hello, world! application?

So we have it, one edit (h:inputText, for whatever reason) and a button (h:commandButton, again like it couldn't be simply a button... nevermind) and we have the next page that shows your name with a nice greeting (using h:outputText for whatever reason, like text nodes were smelly or something... nevermind). Of course we have all the necessary bits and pieces there: a bean with sayHello method, navigation cases set up properly, all the entries in web.xml are there - we're good to go!

Now let's run our glorious application.

1. We're at the start page that kindly asks us to enter our name into the box. Well, we're not that open to mind control so we enter something like "Harry Potter" and click the fancy button that's on the same page.
2. Now we're on another page, this time it's the page saying, that "Harry Potter is most welcome" and "that you can click the back link to get back".

But wait! Have you noticed the address bar? Whatta heck?! It is still pointing to the page where we've had the opportunity to enter our name. We think "something is seriously wrong with our application". But in fact it's not our application that's wrong - it's just how JSF works.

It's not a bug - it's a feature :D And you can't do anything with it. Get over it! Don't look at the address bar - there's nothing of interest to you.

Comments are not comments unless they are comments

The concept of comments is clear to everyone, so it would seem. We developers use them all the time to comment-out code that we'd like to skip temporarily, to better document our intentions. Comments are just plain old descriptions, inactive elements in the code. So it would seem...

Apparently the creators of Facelets didn't think that this is the case. Once you comment out a piece of code (again, for whatever reason) it does not mean it is actually not running!

Some one brave enough decided that the default behavior of comments should be the one of the ordinary template, meaning all the elements that are active (so to speak) are still running! All the references to beans, all the references to resource bundles and what have you are still being used to produce a nice comment!!!

There's of course an option to turn this insane behavior off (facelets.SKIP_COMMENTS) but the default behavior might give you a nice head spin.

jQuery in RichFaces

It's a glorious day! jQuery (my absolutely favorite JavaScript framework) is part of RichFaces! I just found that out.

Well, my happiness didn't last very long. As soon as I realized that it's backed into richfaces-impl jar and that it's an ancient version my lucky day become a nightmare.

RichFaces just have to play nice with everyone, they just can't live without everyone on board. So we have Prototype (a very good library btw) that makes heavy use of the $ sign, then we have jQuery (same thing) and Scriptaculous (obviously).
Did any of the designers of RichFaces ever thought that I might personally dislike the mess they are introducing with this many libraries?

And btw - the ancient jQuery is still ok - but the nice $("#output").dosomething() syntax is gone since jQuery is the one that has to play nice with the rest. That is just not fair! Imagine fixing every single plugin you're trying to use with jQuery to use the full name instead of the dollar sign. Imagine upgrading a set of such plugins... Cool, ain't it?

I've heard that in the latest beta version of RichFaces they have upgraded jQuery to 1.3.2. Let's see if they'll be able to keep up with the latest release once they go GA.

Ajax - the proper way

Here's the problem: I need to call a method that will return some JSON that will be evaluated by the client and according to the result of this operation some action must be taken. All should take place in the browser and the server should return only a JSON response with the data I need. Nothing more.

Let's see - nope! No can do, man! Because you have the feature A, B, C,... Z it's not possible! You have to keep the view state (WTH?) up to date! You need the view state on the other end (what for?).

Here's how it's done in almost any framework out there that makes use of the MVC pattern:

1. Create a method or a class and a method (depending on the technology) that will contain the actual server-side code.
2. Find out the address (usually it's as simple as /controller/method called an action in this case)
3. Use jQuery to make the call and do the rest of the processing.

Can anyone tell me why it is so hard to do in JSF?

Welcome JSF users!

Welcome to this new place in virtual space where you can express your darkest feelings about the sole nature of JSF (Java Server Faces) and other technologies that are connected to it (Facelets, JSF libraries and the like).

This blog has arose from the need to express my personal dislike for that glorious set of utilities that have made my life a misery.

Feel free to stop by from time to time to share your thoughts (be it good or bad) or even lecture me to prove how wrong I am. All comments are welcome.


May the force be with you!