The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

JavaServer Faces - why?

So my boss wants to use JSF for a new webapp...I've not done all that much web application work but when I have I've used Struts.

I'm a complete JSF newbie, and I've been trying to hack together a small demo app.  I'll spare you all the gory details but long story short I _hate_ JSF.  Hate it, hate it, hate it.  I honestly can't imagine how anyone at Sun could ever imagine this as a competitor to ASP .NET.

I can easily get my mind around an event-based paradigm (I've done tons of work in Swing), and a request-based paradigm (Struts).  JSF seems to combine the worst aspects of each.

So my question is, is there some JSF mojo that I'm not getting?  My suspicion is that Faces is some overengineered specification like EJB, JDO, etc. made to satisfy vendors rather than developers.

Are there people out there that love it?  Would you ever use JSF voluntarily?
dave
Friday, February 10, 2006
 
 
I do not know if I would use the word - love.  If you are trying to build complex webapps, especially within a portal for commonality, it can save you a lot of effort in the UI.  I am surprised, after using Struts (and JSPs?) you find JSF that difficult.

Perhaps if you are self taught it is like learning Struts on your own.  You can do it, but I would not use the word "easy".  A two or three day JSF course may just get you over the hurdle.
MSHack
Friday, February 10, 2006
 
 
I haven't used it but I've been interested in hearing what it is like. I've been having to suffer through JSP development on a web application that was very poorly architected to begin with. It is really the pits. I was hoping that JSF would be similar to ASP.NET which is quite nice.
anon
Friday, February 10, 2006
 
 
Hey thanks for replying MSHack.

Maybe an example will illustrate why I don't like Faces, and perhaps shed some light on why it is I'm having trouble.

There is no analogue to the ASP "page load" event, so if you click on a commandlink within a JSF page, the original backing bean gets instantiated again, the data is loaded, all the getters are invoked, and the page is RENDERED AGAIN even though the action isn't bound to the backing bean, and the user is taken to another page.  WHY???

First, its insane that a page load event wasn't in the original spec.  Second, the standard answer to this problem that I see on forums is "just make it a session bean", as if that's somehow a valid solution, either that or a thousand and one hand-rolled lifecycle listener things that don't work reliably.

People just seem to accept the notion that the framework is doing all this unnecessary work behind the scenes.
dave
Friday, February 10, 2006
 
 
Maybe you could use other kind of link that redirects automatically to the other page, without the need to trigger the first page again for redirection? On the other hand, if the "command link" needs to be trigger to pass some information for the other page, then maybe you need some trick to do it without the need to re-render the whole page.

I don't find it strange how it works in JavaServer Faces, because I built my own Web Framework around the idea of components and it works similarly, but without all the extra crap that JSF makes one use.

Tapestry should be better than JSF, but in Java "better" is extremely relative and rarely used. hehe.
Lost but recovering
Friday, February 10, 2006
 
 
I've been wrestling with this a bit more and it looks like a key element of JSF is that whenever it gets a request, it completely rebuilds the view in memory and THEN decides where to navigate to next.

A very good explanation here:
http://blog.exadel.com/?p=19

That blog article also posts a very involved workaround for overcoming this stupid design.  The fact that you have to do so much customization to handle such a basic use case is an ominous sign to me.
dave
Friday, February 10, 2006
 
 
That's a cool reading. Thanks.
Lost but recovering
Friday, February 10, 2006
 
 
Dave I am not really sure I can give a good answer to your questions. Part of it has to do with context.  JSF rendering is a side effect of the desire to allow it to dynamically render to different UIs.  (The menu versus radio button example)

As for whether it is insane to not have a page load event, I cannot speculate.  Perhaps I was too quick to join the "make it a session bean" crowd as the answer.  But each language(?) has its quirks and this is one of JSFs. Perhaps as it matures, some of the workarounds may be rectified.

I appreciated the link to the blog.  Unfortunately, I see your issue.  Without an understanding of JSFs the work around sounds a bit convoluted. Even with an understanding of JSFs, I know what he was trying to explain but it took me a couple of times of reading through it.

While you have probably been here, the Sun JSF site does have a simpler comparison of struts to JSFs that tries to be fair to both. http://java.sun.com/j2ee/javaserverfaces/reference/faqs/index.html#benefits 
but it does speak at an even high level again making it difficult to see 1:1.

Having said all this I do feel your pain.  When I am learning new languages, frameworks, etc. I try to put them into the context of something I do know/understand and coming from struts it does feel like the engine pushing the train.  If you can somehow manage through a couple of implementations you may find you know enough to want to stay away or move closer.
MSHack
Friday, February 10, 2006
 
 
JSF is targeted directly at MS and their visual tools, so you are really supposed to use a GUI to compose the app. They don't expect you to use it by hand.

On the page load, if you are using the component model, which component would be the page? What behavior is there that wouldn't be in one of the components?
son of parnas
Saturday, February 11, 2006
 
 
Son of Parnas, I agree with you, Sun expects to use JSF with one of their IDE products.  I played with Java Studio Creator a bit and rejected it.  One because I don't want to give up Eclipse, two because the tool seems very tightly bound to the Sun One app server, and three because to set up databinding within the IDE you must use Sun's Rowset data access layer, their answer to ADO.

So basically you are giving up everything that makes Java Java, no choice in app server, no choice in data access (giving up Hibernate, one of the main reasons to go with Java over .Net in the first place), no rich components (there is no sortable datagrid, for example).

Java Studio Creator may be OK if you structure the app exactly as the IDE wants you to.  If not, you are in trouble.

Interestingly, the IDE also forces you to create a new backing bean for each JSP page you create.  Pretty much exactly like creating a Struts action.  Is not having to copy properties from form beans really worth all these other headaches?

Two days into this, the ONLY nice feature I'm seeing in JSF is the binding of form fields to bean properties.
dave
Saturday, February 11, 2006
 
 
So, Java is becoming "opinionated?" ;-)
MBJ Send private email
Saturday, February 11, 2006
 
 
Ugh, the horror continues...

I tried to bind a listbox to a backing bean property and a list of option beans using JSF tags.  Sun provides no clear documentation of what the various tag properties do or how to get this tag working.

Eventually I found a blog posting from a guy who was kind enough to document the day he wasted figuring out what should have been clearly documented by Sun.

http://www.crazysquirrel.com/computing/java/jsf/converters.jspx

Two things to note about the article...

One, how the author had to figure this out by trial and error because nothing is documented.

Two, how much extra work you have to do coding these damned converter classes for something so simple.

JSF, I HATE YOU!

I'm going to beg my boss not to use JSF.
dave
Saturday, February 11, 2006
 
 
Yeah, JSF is clearly targeted at RAD UIs for dummies. Struts is also pretty bad, IMHO. For new projects I tend to choose WebWork, but Spring MVC and Stripes also seem like reasonable solutions.
R
Saturday, February 11, 2006
 
 
Yes JSF is supposed to be done in SunOne Studio or whatever the RAD tool is.  Unfortunately the RAD tool sucks balls, therefore, so goes JSF. Stick to Struts - you won't be hearing anything about JSF in 2 years.
Sassy Send private email
Sunday, February 12, 2006
 
 
I also have some unpleasant experience with JSF. I started with a lot of hope with it:
http://write-software.blogspot.com/2006/01/day-4-ui-stuff.html
and I ended rolling my own small web presentation layer.

I think JSF creators made it "flexible" meaning pluggable renderers which I don't need, but having this flexibility costs development time. At the same time, JSF is unflexible once you step out of "recommended" way developing with JSF.


Denis Krukovsky
http://write-software.blogspot.com/
http://dkrukovsky.blogspot.com/
Denis Krukovsky Send private email
Monday, February 13, 2006
 
 
Dave

I'm sorry to see your frustration with JSF.  It's quite reminiscent of my feelings about Tomcat.

We don't use any GUI based IDE for doing out JSF work.  Yep, we just type it in text (albeit using Eclipse).  Although this can be tedious and at times has led to minor frustrations (spelling mistakes and whatnot) it's not as big a grind as you may think at first.  Perhaps this is why we like JSF despite it's lack of maturity.

Of course, if someone gave me ideas on how to use Tomcat better, I think I'd reject them just out of physical dread of even using Tomcat again, so good luck convincing your boss.
Paul Norrie Send private email
Monday, February 13, 2006
 
 
P.S. We got this book before we started with JSF so maybe that helped us too...

 http://www.horstmann.com/corejsf/
Paul Norrie Send private email
Monday, February 13, 2006
 
 
Paul, I'd be very interested to know why you are using JSF.  Are you required to for business reasons or did you select it yourself?  What benefits does it offer?
dave
Monday, February 13, 2006
 
 
Hi Dave

We hadn't done any web dev work prior to using JSF.  We looked at Struts and liked it.  We also looked at JSF and liked it.  Ultimately we chose JSF because of the ability to use different rendering kits, which we're highly likely to need.

It was a unanimous group decision of the three of us.  The only hesitation I had was JSF's lack of maturity.  I tend to prefer mature technologies over the cutting edge.  But JSF 1.2 will be coming soon so that may help some of your frustrations.  I haven't read the spec yet (JSR 252).

We are using Apache MyFaces implementation rather than Suns.  It gives better exception messages for debugging and ironically seems more stable (that's an arm-waving, wishy-washy comment - I don't have specifics).

We also use Jetty.  I can't stand Tomcat.

Hope that helps.  At the end of the day, argue the point with your boss that language/tool/technology choice is just as much about understanding it and familiarity with it as any other argument.  I think you should go with Struts since you favour it.
Paul Norrie Send private email
Wednesday, February 15, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz