Raible Designs

I haven't used JSF yet. But since it is modeled after ASP.NET, it uses a totally different paradigm from the traditional MVC frameworks you listed. Also, JSF needs strong tool support to make development easier. Do you think these factors may have contributed to your less than positive experience?

Posted by Eric Ma on August 07, 2004 at 01:49 AM MDT #

The less than positive experience is because Matt wants to write an app while asking a million questions all over mailing lists and not investing the time to learn. Since JSF doens't have anyone to hold his hand he wasn't able to learn it by himself.

Posted by 66.167.118.157 on August 07, 2004 at 01:53 AM MDT #

I'm sure Matt is more than capable of learning JSF all on his lonesome - but if it doesn't make developing applications easier/better/faster etc. what's the point?

Posted by Cam on August 07, 2004 at 03:38 AM MDT #

If you refuse to learn a new way you won't see how JSF makes developing applications easier/better/faster.

Posted by 66.167.118.157 on August 07, 2004 at 03:41 AM MDT #

Anonymous (if that's your real name..) - why not detail and enlighten Matt and his readers as to how JSF makes developing applications easier/better/faster? Matt's not perfect (sorry, Matt ;-), but he's blogged about and been able to grok quite a few different frameworks, libraries, and technologies, so I trust a lot of what he says. You on the other hand we have no clue about, since you don't offer either a name or any useful information. You took the time to read his post and respond, how about clueing in the clueless on how JSF is the cat's meow? Are Matt's gripes about specific items valid? BTW, I happen to know zip about ASP.NET, but last I heard JSF was meant to be Swing-like. Could that be the case?

Posted by gerryg on August 07, 2004 at 04:00 AM MDT #

JSF without the tool support? No one tries to write .Net apps without Visual Studio, it is simply unheard of. Big vendors will come in and have their chance at competing with .Net, that is what JSF is all about. It is not "open source" like the other frameworks used.

Posted by 66.142.96.71 on August 07, 2004 at 04:02 AM MDT #

Mr. Anonymous,

I agree that I asked a lot of questions on mailing lists and didn't invest much time to learn JSF. However, I did the same thing with WebWork and Tapestry. Not only were my questions answered, but I was able to accomplish my desired tasks in a reasonable amount of time. It's almost like an experiment in newbism. I'd argue that JSF is similar to Tapestry and Tapestry seems to be a much more capable framework.

Posted by Matt Raible on August 07, 2004 at 04:06 AM MDT #

seems to be a recurring theme seeing people mentioning how tools will make JSF shine, I'd much rather use a simpler framework but still very capable that gets the job done without having to depend on these tools, sooner or later depending on these tools in going to get you in trouble when you try and do something outside their capability

Posted by Francisco Hernandez on August 07, 2004 at 04:43 AM MDT #

Matt,

I've been using struts for awhile and thought I would start to look at JSF in the near future as I heard that JSF would replace struts eventually. My problem is struts (with tiles) has basically met all my needs until now rather nicely. Your comment:

"If you know Struts, Spring MVC and WebWork are fairly easy to learn."

makes me wonder if I am missing out on something from these other frameworks. Do they all do the same thing, or is there different advantages to each framework? Basically, why should I migrate from struts?

BTW, thanks for maintaining such an interesting blog!

-Pat

Posted by Pat on August 07, 2004 at 05:29 PM MDT #

Pat,

My opinion is that if Struts works for you, there's not much reason to use another framework. My personal reasons for learning Spring MVC and WebWork was to see if I was missing out on anything. What I found was that their main advantange is you can use your model objects (POJOs) to back your forms. No need for ActionForms. However, using XDoclet, you can generate your ActionForms from POJOs - so it's only a minor build-time advantage.

I also like how Spring MVC and WebWork aren't as tied to the web environment. However, it's not that big of a deal. The WebWork guys claim that the no-tie-to-the-web is an awesome feature, but it's not that cool - just kinda neat. You could argue that Spring Controllers and WebWork actions can be easily tested outside a container, but so can Struts Actions (using MockStrutsTestCase).

As far as tag libraries, Struts' tags remain the best of the bunch. WebWork's tags are cool b/c you have to type a lot less, but sometimes they do too much and the whole single quote/double quote thing is annoying. The nice thing is you can customize the HTML produced very easily. Spring is nice because their tags don't emit any HTML, but it does result in a lot more LOC in your JSPs. Although, I do have to admit that complete control over all the XHTML produced is nice. I really like how you can easily use Velocity with Spring, but you can use it with WebWork and Struts too.

If I was to start a new project tomorrow, I don't know what I'd choose. It'd depend on the deadline. I pretty much know how to do everything with Struts, so I'd probably never bang my head agains the wall - which would be nice. If members of the team wanted to use another framework, I'd be open to that too. My main goal with all of this is to integrate them into AppFuse and make it easier to get started with each one of them.

Posted by Matt Raible on August 07, 2004 at 06:12 PM MDT #

Thanks for the insight Matt! The fact that you can use your POJOs instead of ActionForms does sound nice. That's pretty much the only headache I had with Struts although I've developed my own way of easily converting between the 2 now fairly nicely. I think I'll stay with Struts for the time being and watch for more feedback from the early users of JSF and the other frameworks to see what's going on.

-Pat

Posted by Pat on August 08, 2004 at 04:36 PM MDT #

"If you refuse to learn a new way you won't see how JSF makes developing applications easier/better/faster." - Anonymous And exactly which part of Matt's post indicated his refusal to learn? If you cannot realise the benefits of a new framework relatively quickly you've got little incentive to dedicate valuable time for learning more. Exactly how to develop software which is easy to use as well as being clever and elegant is a problem over which many herbal teas have been mulled, and much ink wasted. If we are to take up JSF on-mass, our investment (read: risk) needs to be low-moderate, and the benefits great. This the reality of business - which is why we develop software, eh?

Posted by Cam on August 09, 2004 at 01:22 AM MDT #

Matt, I don't know Tapestry, but something that is attracting me to JSF is the ability to create reusable components. How the other frameworks handle this issue. Regarding complexity, EJB was also supposed to have tools to help it. It never happened... Sun released Studio Creator to support JSF and I have to confess that it looks really promising. One last thing: Sun claims that JSF is for use in "intranet" sites, not something that is open for the world to see. I think JSF's performance must not be stellar, since it has so many steps between the webpage and your code...

Posted by Mauro on August 09, 2004 at 06:09 PM MDT #

This framework posts have definately been interesting! Personally, I've got a strong bias against JSPs in any form, so I've avoided Struts. I've gone with Niggle & Freemarker but I've had a look at BarracudaMVC, both of which have a interesting takes on things!. Anyway Matt, the question is, do you have any more to say on Tapestry? :-) I've got mixed feelings about it at the moment, being tempted by it's good 'press' but being put off by the raft of documentation marked as "out-of-date". I could buy the book, but it's a bit of a waste if I'd be better off just going with something like SpringMVC & FreeMarker/Velocity. (I'd probably be more positive on Tapestry if I used Eclipse, as I hear the Spindle plugin's impressive, but I use IntelliJ and I'm not really sure if want to try & get used to both IDEs!)

Posted by Gwyn Evans on August 09, 2004 at 06:09 PM MDT #

How funny. This remindes me when I used to critisize EJB's, people would take it personal. Anyway, I agree with Matt. JSF would be on bottom of my list. (My suspicion is that Mr. Anonymous is a newbie, since I think that only newbies like complexity) .V

Posted by 68.94.21.199 on August 09, 2004 at 11:56 PM MDT #

Hii All, I was trying to use JSF with struts using struts-faces and myfaces implementation. But after banging the whole day...it seems to me that JSF is still not matured..no clear information...no clear documentation (Like Struts). I can't believe that Craig R. McClanahan is also on the JSF Reference Imple. Working with JSF is not worth at the moment. Vote for Matt Raible.

Posted by Armin on August 10, 2004 at 02:20 PM MDT #

Matt, You say in your post that the problem is with the specification, not the implementations. However, the only points you made that are related to the specification are the requirement for form posts and the lack of a simple way to internationalize application-generated messages. (By the way, you can create normal hrefs using the HtmlOutputLink component (<h:outputLink>), but they can't execute actions. Most of the issues you mentioned were either specific implementation bugs or issues with specific component implementations. It's fair to point out that the standard UI components are useful, but they're really only the tip of the iceberg. Several companies (including Oracle and several smaller companies) either have, or will, be introducing better components. It's also fair to note that JSF is newer than the other frameworks you've used, so you can't expect the same amount of traffic in the on-line forums. Kito D. Mann Author, JSF in Action http://www.JSFCentral.com - JSF FAQ, news, and info

Posted by Kito D. Mann on August 10, 2004 at 04:20 PM MDT #

Kito,

You and David have said the same thing: I've stated I have a problem with the specs, but there's not much proof in my post. I'll agree with you. The few minor issues I have (no easy way to i18n success messages, no HTML escaping on <h:messages> and ugly validation messages) do seem to be spec related as the deficiencies exists in both Sun's RI and MyFaces.

I think JSF is a good idea, and seems easy to work with at first, but from a hand-coding perspective, there's some silly stuff - like having to load a resource bundle after the <f:view> tag. Why can't <f:view> be in a SiteMesh decorator? Why can't the resource bundle be declared for all pages, rather than needing to be declared on each page you want to use it? These are spec issues IMO.

I was also pretty disappointed in the <h:dataTable> component. I heard a lot of hype about it and how it was just as good as the displaytag - but it doesn't even come close to the functionality that the displaytag has. This is fine since I can use the display tag in JSF - but I can't invoke an action's method with the display tag and an outputLink. That sucks. I have a few simple things I like in my applications and JSF couldn't provide all of them easily:

A sortable/pageable list of data. It's possible, but you have to add special sorting logic for each class. JSP already has this with the display tag - I'd simply like to be able to use it in JSF.

Bookmarkability. Container managed authentication gives us a great way to offer users the ability to bookmark pages. If everything is a POST with JSF, we lose this ability. Sure there's the HTMLOutputLink, but if we can't invoke actions, what good is it?

Clean and easy to read validation messages. The validation messages in both MyFaces and Sun's RI are not something you'd deliver to customers. What's wrong with making clean messages out-of-the-box? Tapestry seems to have no problems doing this. All the other MVC frameworks make you specify your own - which is fine with me.

Easy cancelling and multi-button form handling. JSF does this well - better than the rest I'd say.

Easy testability. Because of the plethora of JavaScript, JSF apps are difficult to test with tools like jWebUnit and Canoo's WebTest. Don't get me wrong, I love JavaScript - but an application should be able to be tested w/o it.

Success Messages. JSF does success messages OK - it's a pity it's not easier to get a resource bundle and it's a shame that you can't escape HTML in the <h:messages> tag. This seems like an oversight to me.

I hope these issues are fixed soon b/c I do think JSF has potential. It simply doesn't meet my meager requirements to write a basic webapp.

Posted by Matt Raible on August 10, 2004 at 04:59 PM MDT #

Hi,
Disclaimer - I'm a JSF newbie.
I'd like to add to the discussion another JSF shortcoming I hope would be addresses in future specification:

Iterating Layout - JSF can iterate a layout using either <h:dataTable ...> or <h:panelGrid ...>, both rendering as tables. This is VERY restrictive (can't even use a simple list). Solutions I've found suggest either a Tapestry-like solution or mixing JSF with JSTL. Using JSTL in conjuncture with JSF is very straightforward but is also restricted - no JSF tags are allowed (well, recommended actually, from what I understand the result is unpredictable) within JSTL tags. So this means using where necessary JSTL only, which is a shame. The Tapestry-like solution is interesting but nowhere near Tapestry's capabilities (not that that there was such an intention). More (and much more) on this issue.

Pretty much the same goes for conditional rendering - tweaking the "render" attribute (the JSF way as I understand it) doesn't provide as much control as a simple JSTL <c:if></c:if> or:

<c:choose>
 <c:when test="${userHandler.currentUser != null}">
 <c:out value="${message.hello}" /><c:out value="${userHandler.currentUser.displayName}" />
 </c:when>
 <c:otherwise><c:out value="${message.site_header_welcome_visitor}" /></c:otherwise>
</c:choose>

Posted by Ophir Radnitz on August 11, 2004 at 12:08 PM MDT #

There is a framework that has a visual editor for every java IDE, really easy to use, totally object oriented, mvc architecture, handles pure html files as templates, does not need a lot static xml configuration files, has component refreshing (partial updates), powerful validation framework (similar to .NET), page state management (similar to viewstate), has an abstract UI layer that hides all web specific problems, skinable components.... WebOnSwing (http://webonswing.sf.net) - Multiple Environment Application Framework is an open source project distributed under LGPL license.

Posted by Fernando Petrola on August 11, 2004 at 03:20 PM MDT #

Regarding you're problem with simple success messages I'm not sure what 6 lines of code you're talking about but I believe I can do simple success messages in 1. By using Spring to inject a message bundle into my JSF managed bean. You mentioned that you used the JSF integration from Spring CVS? You really should try the Spring-JSF integration project. The Spring-JSF project provides a much better and more thorough integration in my opinion. I don't know why Spring decided to only provide a VariableResolver. Mike

Posted by youngm on August 11, 2004 at 03:30 PM MDT #

Then there are all the undocumented bugs/restrictions that JSF (or Sun's implementation) puts on request scope, which forces way too much into session scope.

On the other hand, I think the messages tag is a great idea. Sun's renderer is what's broken. But it was very easy for me to write and deploy a better renderer. Now if only the messages would survive a redirect....

Posted by Ray Davis on August 11, 2004 at 03:31 PM MDT #

One further note, after thinking about it you don't actually need the spring-jsf project to inject a message bundle. You could doing with the variable resolver when you create your managed bean. Regards, Mike

Posted by youngm on August 11, 2004 at 03:32 PM MDT #

The best part about not having your web application code tied to the web environment is that your action classes don't extend the Servlet API. Struts actions extend a concrete class that has a dependency on the HttpServletRequest and HttpServletResponse. This makes your actions very difficult to test as well as not being reusable outside of your web application.

Posted by Eric Hauser on August 11, 2004 at 03:34 PM MDT #

I just finished a project using JSF. I learned it along the way. I recommend other web application projects to use it, but only after the developers have read the spec. There is a learning curve for JSF that is just as high as it was for Struts two years ago when I knew Struts was a crappy way to do web apps. But that's not the case for Struts now. I can develop web apps easier,better,faster with JSF because I a software developer, not because JSF is filled with magic pixie dust.

Posted by Aris on August 11, 2004 at 04:18 PM MDT #

> You should really try the Spring-JSF project.

Mike - I did use the spring-jsf integration project, and found it worked great. The major reason I switched to MyFaces is b/c they said they had a sortable/pageable table - but it's not as full-featured as I'd like. I also switched to using Spring's native VariableResolver, which works - but MyFaces logs errors. I should probably change back to using spring-jsf as it seems to be more robust. Your idea about injecting messages with Spring is a good one - thanks!

Posted by Matt Raible on August 11, 2004 at 04:24 PM MDT #

Matt, On a side note, has anyone noticed any difference in speed (page loading) using other frameworks tag lib's. I recently read a post indicating that switching to the JSTL resulted in marked performace gains from Strut's tab lib's?

Posted by Chad Smith on August 11, 2004 at 06:07 PM MDT #

If you ever figure out whats up with that ThreadDeath let me know, because I'm experiencing the same problem on a struts app when testing in tomcat.

Posted by Andre Mermega on August 11, 2004 at 07:35 PM MDT #

Interesting comments and thanks Matt for the Blog and your dissemenation of information related to building Enterprise solutions. I spend a lot of time writing code generation and automation tools that can generate the inputs to frameworks like Struts, BEA platform, Appfuse, etc... (I just went through the process of building one for Appfuse) from case models or some other high level description language. The idea being to allow less experienced associate programmers or higher level business analyst build solutions by writing as little java code as possible, if any at all. In my opinion JSF is a standard that addresses the binding of 1) look & feel, 2) UI functionality, 3) Business Objects or Models in Struts terms, and 4) Back end services through a descriptive approach. They have tried to isolate the common characterisitcs in each of these bindings to a descriptor syntax. The spec is really a blue print for code generation of an MVC applicaiton. Tools like Sun Java Studio Creator and Fabrique from Idea Inc. really leverage the spec and show how it can be used. I was able to create a little Database driven application with login and CRUD capabilities using Sun's Java Studio fairly quickly and without writing a single line of source or reading any documentation. Its still has a ways to go but it getting close. JSF really seems to be well suited for building tools like this and not so well suited as a stand alone programming language syntax.

Posted by Steve on August 11, 2004 at 07:45 PM MDT #

and what Oracle is doing for JSF components?

Posted by Dmitry Namiot on August 11, 2004 at 08:45 PM MDT #

Has anyone tried SOFIA (www.salmonllc.com)? Any thoughts or experience with this MVC?

Posted by Stephen Pasco on August 12, 2004 at 11:34 PM MDT #

I think you're too in love with struts to have a clear sight on what's going on. I tested recently JSF, and having had not so much pleasure practising struts, I can say I prefer JSF. It requires a little bit more words to get something work, but I like the global approach, and I can feel it will *probably* win the game. We should remember that Craig R. McClanahan, creator of struts and major contributor of the JSF specs, recommends the migration to JSF.

Posted by toto on August 13, 2004 at 08:04 AM MDT #

- I have tried to meet a tight deadline with JSF 1.1, and it is a no-go. This may be a function of its newness.

- I have tried and tried to find simple descriptions of the expression language, but all I find are BNF notations. I am sure that with Tomcat 5, the expression language comes in (we are on 4.1, so the expression language is restricted to unary operators on method results).

-The JSF syntax is easy, but the components are buggy. Nested tables DO NOT work, even with the latest version. (ActionEvent from within a nested table comes in with data related to only the last nested group, not the one it was clicked on). Eevn though the ids are correct in the generated html, I cannot find that id the ActionEvent, so my workaround efforts are blocked.

- I just need to turn on/turn off components, but I cannot figure this out. I have not figured out how to nest components within a non-visible container.

- I like the ease of putting listeners, etc. on the jsf tags. I am not sure how to inflate the model from the database... I would like to do this from one spot. Is there something called during in invokeApplication?

- The jsf jars clutter up the log files with SAXParseExceptions because their built-in xml files do not specify <DOCENGINE dtds lines.

----------- On to SOFIA... - I have used SOFIA for over 2 years now, and with some work, it has done everything I have asked it to. The bookmarking is not straight-forward, but we did it. Nested tables require the code to manage session variables, but we did it.

- SOFIA is session-based only, so users get funky error messages occasionally.

- SOFIA is fast and once all the kinks are worked out, it is quite fast to develop in.

- We use POJOs to manage transactions using their BeanModel. This is good. We bypass the automated SOFIA datastore retrival/update logic in favor of POJOs. The good thing is we can do this easily.

- Overall, SOFIA is hard to learn, and only one other person in our area has bothered. The difficulty lies in the things you have to turn off in their event handling model. Once you do that, and captured the results in a template controller, things go smoothly.

- The Dreamweaver integration is OK, but it is buggy. We used it for two weeks and kept losing code because the SOFIA Dreamweaver Javascript modules kept bungling things. Hand-coding the SOFIA framwork is fine. I still occasionally Dreamweaver for layout.

- SOFIA has quirks in its event model. You must program in code to turn off certain calls.

- The html components are missing quite a few javascript attributes (each attribute in an html tag has to have a matching SOFIA Java method).

- I like the control that the SOFIA containers provide. I can toggle entire groups of components with a single line of controller code based on user permissions. On the jsp-side, all I have to do is to group these components within that container. There is no equivalent within JSF.

Posted by James Violette on August 16, 2004 at 03:20 AM MDT #

I've looked into jsf for a while, ever since it was in beta. I've not had good experiences with it either. And forget about any kind of help. There's more action going on in graveyard on a saturdaynight then in the forums.

Posted by joneric on August 16, 2004 at 07:08 PM MDT #

Matt,

So many people have said so much (that I haven't had time to read). I'm probably not going to say anything new, but here's my reply anyway :-).

> You and David have said the same thing: I've stated I have a problem with the > specs, but there's not much proof in my post. I'll agree with you. The few minor > issues I have (no easy way to i18n success messages, no HTML escaping on > <h:messages> and ugly validation messages) do seem to be spec related as the > deficiencies exists in both Sun's RI and MyFaces.

Fair enough. I'm not too worried about component deficiencies, though, because vendors will quickly fill in those gaps (and already have to some extend). The standard components are definitely minimialistic.

> I think JSF is a good idea, and seems easy to work with at first, but from a > hand-coding perspective, there's some silly stuff - like having to load a resource > bundle after the <f:view> tag.

I agree with you the specifying <f:loadBundle> is a pain, but you can't say that other frameworks don't have strange requirements like this one. It's not _that_ big of a deal.

> Why can't <f:view> be in a SiteMesh decorator?

I can't say much about this, because I haven't tried using the two together. I'm assuming that you tried to use the <f:subview> tag, correct?

> I have a few simple things I like in my > applications and JSF couldn't provide all of them easily: > * A sortable/pageable list of data. It's possible, but you have to add special > sorting logic for each class. JSP already has this with the display tag - I'd simply > like to be able to use it in JSF.

I do think that the data grid component could be improved. Again, this leaves the door wide open for vendors, and there are already better grids.

> * Bookmarkability. Container managed authentication gives us a great way to > offer users the ability to bookmark pages. If everything is a POST with JSF, we > lose this ability. Sure there's the HTMLOutputLink, but if we can't invoke actions, > what good is it?

Fair enough.

> * Clean and easy to read validation messages. The validation messages in both > MyFaces and Sun's RI are not something you'd deliver to customers. What's wrong > with making clean messages out-of-the-box? Tapestry seems to have no problems doing > this. All the other MVC frameworks make you specify your own - which is fine with me.

I don't see how having poor error messages is _worse_ than having no error messages at all. At least you have starting point. And they're easy to change.

* Easy cancelling and multi-button form handling. JSF does this well - better than the rest I'd say.

True.

> * Easy testability. Because of the plethora of JavaScript, JSF apps are difficult > to test with tools like jWebUnit and Canoo's WebTest. Don't get me wrong, I love > JavaScript - but an application should be able to be tested w/o it.

I'm not sure this is really a JSF problem, because a lot of real applications use JavaScript. Shouldn't a testing tool be able to deal with that reality? And, as Geary pointed out, testing application logic in backing beans is certainly doable using JUnit.

> Success Messages. JSF does success messages OK - it's a pity it's not easier to get > a resource bundle and it's a shame that you can't escape HTML in the <h:messages> > tag. This seems like an oversight to me.

True. But I don't think it's a major issue, and I think other frameworks have similar issues that look like oversights.

I really think most of your complaints are minor. The only one that seems like a major issue is bookmarkability. If JSF's standard data grid was as powerful as displaytag, I think you would have been much less frustrated. For better or worse, the EG put a lot more emphasis on designing the framework than on making the standard components exceedingly powerful. The result is a really powerful framework and a pretty basic set of standard components.

Posted by Kito D. Mann on August 20, 2004 at 09:12 PM MDT #

Is it just me? I found JSF much easier than Struts. Oh well :-)

Posted by Neil Laurance on September 01, 2004 at 01:16 PM MDT #

And before anyone says anything, yes I know Craig McClanahan was involved in both :-)

Posted by Neil Laurance on September 01, 2004 at 01:19 PM MDT #

What a great discussion. Even though I'm coming here 2 weeks after the most recent post, I'd like to contribute.

In an effort to enhance the reusability of a UIGridPager and 2 associated renderers that I wrote, I decided to read the JSF specification. As I tried to make notes about things I can do to revise my implementation, I kept coming back to a single nagging problem: JSF's STATE_SAVING_METHOD. Because the JSF specification allows this to be configured at deployment, it effectively eliminates the ability to send request parameters via the GET method.

Matt, this goes back to your bookmarking and test case gripes. My major gripe is that I don't want to count on javascript support from my http/html clients. If I could count on javascript support from all of my clients, I'd have much less use for server-side validation (since I could do most of my form validation right on the client using javascript). In order to render an html hyperlink for my pager, I have to create a hidden form field whose value is dynamically changed by an onclick event before submitting the form. The onclick event attribute is useless if your client doesn't support javascript.

Perhaps this is why JSF is targetted mainly toward 'intranet' applications, since at least there you can guarantee javascript support. But then what's the use of having a different renderkit for WML? Do you really want to spend the effort so that your intranet can be accessed from cell phones and PDA's? I think the JSF framework would be much more reusable if form submits (i.e. 'JSF requests') could be initiated using a GET query string. However this would only be possible if your client's state was saved on the server, or if the state could be saved on the client using a much shorter string (like a JSESSIONID).

The main lesson I've gleaned from my JSF experience is the ability to recognize that the spec is only in it's 1.x version. Does anyone remember the EJB 1.x specifications? CMP was screwy, all beans were remote, and everything was synchronous. EJB 2.x has fixed a lot of that stuff only after vendors and developers griped about it. It's not time to adopt JSF in your applications just yet, unless the standard implementations satisfy your needs. It will be interesting to see how JSF evolves though, so don't forget about it entirely.

Posted by Sophomore on September 16, 2004 at 02:17 AM MDT #

and what Oracle is doing for JSF components?

Oracle's JSF component library is called ADF Faces and you can download and play with our ADF Faces Early Access Release (EA7) in whatever environment you use for your JSF development.

If you're using JDeveloper 10g, this article explains how to use ADF Faces with it. Steps would likely be similar with other IDE's that support tag libraries and JSP-based development.

Lastly, we've previewed at JavaOne 2004 and various conferences the visual JSF features coming in the next major release of JDeveloper 10g, due out in 2005.

Posted by Steve Muench on September 22, 2004 at 04:28 PM MDT #

"For better or worse, the EG put a lot more emphasis on designing the framework than on making the standard components exceedingly powerful. The result is a really powerful framework and a pretty basic set of standard components."

Speaking as one who has never used JSF, my comments maybe wrong. However, this diffently seems like it's for the worse. We have this all powerful framework and we can't do anything useful until vendors can produce components or we roll our own. Then we have a myriad of components all doing the same thing but slightly differently. Different API's to use them, vendor lock-in, etc. Doesn't sound like the best way to go about things. But that is Sun, give the vendors all the power and stick the developers with the problems.

Posted by Jason on September 24, 2004 at 01:56 PM MDT #

Ceki Gülcü's recently updated Think again before adopting the commons-logging API contains some hints on where the ThreadDeath might be coming from. I am using Struts with commons-logging and log4j in Tomcat 5 and get the ThreadDeath more and more often upon reloading a webapp.

Posted by Thomas Plümpe on October 14, 2004 at 12:43 PM MDT #

Mat, There is a framework for everyone and there are frameworks that don't suit everyone's taste. Perhaps JSF is not for you but I learned in on my own mostly and really like it. To me it is far superior to Struts, and yes, even Tapestry. I have used Struts, Tapestry, JSTL, and JSF. My preference is JSF! Now, JSF, Hibernate, and Spring is a really good combination (for me). Often in the beginning when learning anything new the temptation is seek complicated solutions while overlooking the simplistic. This approach greatly impeds the learning process. There are hundreds of thousands of happy JSF programmers who would rather "fight than switch", and by the same token you can find programmers (perhaps in smaller numbers) that would say that about Tapestry and other frameworks. Bottom line - Pick your poison and stop bad-mouthing others because you don't get.

Posted by eusdart on October 15, 2004 at 01:31 PM MDT #

Posted by 69.193.88.30 on November 08, 2004 at 03:27 AM MST #

Posted by 69.193.101.102 on November 12, 2004 at 12:54 AM MST #

hi sandi oh i hate you glandi ok hello i am gondy the father of 14 kids hello i am 3 foot and 5 ins i am glad you are reading my little story oh ok no what i mist say is my son is be coming a man he is 48 years old he is 7.5 he ways 189lb he's name is yao mang i love my son i sat on cool to day so i feel so good and i sat on a big gac gac oh i was beatifull with two L.L ya just like you got hing the movie yes ok gia you 2 cent bag ok i love you gaji nokie ok bye ps.. i love nick carter and justin timberlake ok bye

Posted by gondy bullsais on December 13, 2004 at 06:50 AM MST #

Java is becoming so confusing to the non-java developers that is scares us all away.

Posted by net on January 16, 2005 at 05:05 AM MST #

sad

Posted by 83.89.176.250 on May 03, 2005 at 09:20 AM MDT #

I think JSF it's great, but every thing you can do with it, you can do without... So, the best framework stilll depends on the nature of the project and on the skills of the developers envolved.

Posted by Cristiano S. Neves on July 10, 2005 at 09:16 PM MDT #

I want to know about the way to convert an application which is compleatly developed using spring to one using jsf-spring integration. The example that was provided in this article was of great use. but i want to know about which part of the application performs the task of the Controller(Dispatcher Servlet) in a spring application.

Posted by reena on August 23, 2005 at 07:08 AM MDT #

komment

Posted by 195.13.39.137 on September 06, 2005 at 04:23 PM MDT #

I would just want to confirm Matt's earlier comments about Struts versus Spring MVC. If your team is familiar with Struts and productive I would not bother switching to Spring MVC. Its not that Spring MVC is bad, its just that its not sufficiently better to warrant all the down time your team will learning it. This has been my recent experience.

Posted by Malcolm Edgar on January 20, 2006 at 03:14 AM MST #

7yuiuyiuyi

Posted by 196.12.44.162 on March 31, 2006 at 12:35 PM MST #

i love you

Posted by jack yan on April 30, 2006 at 09:46 AM MDT #

Hi Matt! I don't know if you have seen it already, but there is a mechanism to include the "label" of an input component in the validation message for that component. I agree that it involves a bit of a work but nonetheless, it's not unachievable. You can use the generic attribute specifier to create a "field reference" for your input component and as it's value, specify the value of the label used for that component. Then, all you have to do is create your own PhaseListener and in the beforePhase() method of the RenderResponse phase, get all the client ids which have messages associated and then look for the ones with field references. For those components, get the value of the attribute and "prepend" it to the message. That's it, you've got your validation message with the "label" included.

Posted by Robin on June 22, 2006 at 09:41 AM MDT #

Coming from an action-structured world instead of a component-structured one, I can understand Matt's reactions to JSF. I was a big Struts advocate in the pre-JSF days and I've used Spring MVC and FreeMarker as well... However, having used MS .NET, I wasn't as shocked when I moved on to JSF. JSF's application architecture is quite different from Struts, Spring MVC and FreeMarker because it is GUI-based (or component-based). The idea behind it is that the screens are driving the application, not the backend-business or actions. When you think about it, it makes a lot of sense and put the focus on the user experience first, then the business. Obviously, like MS .NET, it helps if you have WYSIWYG tools to design and build your app and then fill in the business bits behind the scenes once that is done. Design paradigm aside, I like JSF primarily because it is a STANDARD and, like it or not, most people who hand out money to developers feel safer doing so when they see the word STANDARD plastered all over your proposals. It means they won't get locked into some proprietary technology that is supported by a single individual or group, no matter how popular at the time... These people are thinking in terms of return on investment and long shelf-life, not in terms of what's hot now. They are willing to sacrifice some ease of use and growing pains to avoid being locked-in and having things fall apart when everyone abandons Struts or Spring MVC. They are thinking in terms of YEARS of support and use. Standards evolve slower because of the process of standardization and having to maintain backward compatibility. So, there are obvious growing pains. HOWEVER, overall stability and backwards compatibility make it an attractive option and future upgrades usually involve minimal changes, most of which are optional. Just my 2cents.

Posted by John Doe on November 08, 2006 at 03:07 PM MST #

Vote for Matt. Never, never go for jsf, never without tool support, otherwise u are going to kill your self. its like .net without visual studio. for me webwork, Struts 2,Tapestry, is much better.

Posted by Sudhir Nimavat on January 15, 2007 at 10:51 AM MST #

so, it's over 2 and a half years since the article was developed. Time has passed; it'd be a nice favour for those who are researching JSF to have some kind of check-in or update on this. an example of how the web can sometimes not be helpful. :) j.

Posted by jon on May 07, 2007 at 08:49 PM MDT #

heh i think i may have my answer: this blog, in general. :D j.

Posted by jon on May 07, 2007 at 08:52 PM MDT #

Take a look at JDeveloper and their ADF Faces.

Posted by james on May 09, 2007 at 06:41 PM MDT #

Avoid JDeveloper at all cost ! ADF Faces is of little value right now. Constrained layouts, few components, buggy... First you think you save a lot of time with the designers, and then you realize you are going to have a very hard time debugging this crap.

Posted by Bob on May 15, 2007 at 02:56 AM MDT #

so, it's over 2 and a half years since the article was developed.

And in my opinion, not much is different ;). Having used it for about 10 months now, I just can't like it or recommend it to anyone. The number of times I've had to work around a limitation or nuance of JSF to do seemingly simple things has cost me more time than it's worth thinking about. Facelets does provide some help, but there's better alternatives.

JSF primarily because it is a STANDARD and, like it or not, most people who hand out money to developers feel safer doing so when they see the word STANDARD plastered all over your proposals. It means they won't get locked into some proprietary technology that is supported by a single individual or group, no matter how popular at the time

But with the amount of hacking around people need to do, it's unlikely anyone else will understand it anyway. How does using a non-standards defined project lock an end user into proprietary technology? Most of the alternatives are open source. Besides, just because it's a "standard" doesn't make it the best choice.

Posted by Marcus on May 15, 2007 at 06:42 AM MDT #

Our project has sunk a lot of money into JSF development, and we have almost nothing to show for it. We have talented developers, but JSF just makes you do a lot of work to avoid doing work.

Once you decide to do something that JSF wasn't *explicitly* designed to handle, you have a lot of coding ahead of you. And as Matt said, even after that you may not be able to get the results that you want.

Posted by Etienne on August 16, 2007 at 09:57 PM MDT #

Most of what your are complaining about is due to your lack of experience writing software from hand. If you worte your app more like swing and focussed on component creation, you would see how powerful JSF really is. I work for a large software development company and write custom JSF components that our less tech savvy developers can just drop into their page. Abstracting 99% of the code from the point of view of the presentation layer. Their JSP pages are usually a one liner with setting properties, resulting in a grid that holds many different input and output components. All they needed to do was write 1 line of JSP and adding 1 .jar to the lib folder .... maybe you should go back to school.

Posted by 209.6.185.137 on August 24, 2007 at 10:03 PM MDT #

Most of what your are complaining about is due to your lack of experience writing software from hand. If you worte your app more like swing and focussed on component creation, you would see how powerful JSF really is. I work for a large software development company and write custom JSF components that our less tech savvy developers can just drop into their page. Abstracting 99% of the code from the point of view of the presentation layer. Their JSP pages are usually a one liner with setting properties, resulting in a grid that holds many different input and output components. All they needed to do was write 1 line of JSP and adding 1 .jar to the lib folder .... maybe you should go back to school.

Posted by 209.6.185.137 on August 24, 2007 at 10:04 PM MDT #

Most of what your are complaining about is due to your lack of experience writing software from hand. If you worte your app more like swing and focussed on component creation, you would see how powerful JSF really is. I work for a large software development company and write custom JSF components that our less tech savvy developers can just drop into their page. Abstracting 99% of the code from the point of view of the presentation layer. Their JSP pages are usually a one liner with setting properties, resulting in a grid that holds many different input and output components. All they needed to do was write 1 line of JSP and adding 1 .jar to the lib folder .... maybe you should go back to school.

Posted by Shawn on August 24, 2007 at 10:05 PM MDT #

Most of what your are complaining about is due to your lack of experience writing software from hand. If you worte your app more like swing and focussed on component creation, you would see how powerful JSF really is. I work for a large software development company and write custom JSF components that our less tech savvy developers can just drop into their page. Abstracting 99% of the code from the point of view of the presentation layer. Their JSP pages are usually a one liner with setting properties, resulting in a grid that holds many different input and output components. All they needed to do was write 1 line of JSP and adding 1 .jar to the lib folder .... maybe you should go back to school.

Posted by Shawn on August 24, 2007 at 10:05 PM MDT #

JSF is excruciating. Matt had it right 3 years ago. His analysis is spot on. I can't think of a single thing to praise about JSF other than rates for contractors who know JSF.

Posted by JSF Convert on January 10, 2008 at 06:45 AM MST #

I'm going nuts with JSF. It's almost refreshing to read this. The sad thing is it was written 3 years ago yet a lot of the problems still remain. I think in theory JSF is a good idea. The whole component model, and being able to map a link or button directly to a method. But when I look at the amount of Javascript produced, and the fact that everything is a form submit. I mean I have a button that does only javascript actions and still submits the form unless if I throw a "return false" into the onclick attribute. I consider a hack to the framework since the expected behavior is to submit the form. I find it impossible to keep the page light (in terms of bandwidth consumption). Good thing the project I'm working on is for intranet use only.

I'd say my biggest gripe with JSF though is that the components never do what I want, or they produce garbage HTML, so I have to either override the renderer and write my own, or just write a whole new component. Pretty much everything I do requires a new component, oh that's easy... really? It's minimum 3 classes, plus I have to edit (or create) a tld file. Then I have to add the renderer and component to faces config. It's just a big pain really.

I've discussed with one of the other developers and we both agreed that after a while we should have a solid library of our own components and maybe then we can develop applications more quickly.

I find the myfaces mailing list alright. But the documentation is very lacking, even 3 years later.

Posted by Matt Rossner on February 12, 2008 at 09:54 PM MST #

I know it is late comment for this post, but I just want to share some of my experiences and ideas about working with jsf. By the chance I involved in couple of projects using Jsf, myfaces, Tomahawk and richfaces and shale and ? many others!! I have heard a lot about jsf is becoming popular because it is standard! Aside from marketing calls, it can be decision of some architects who read or test jsf features on simple application. BUT as a developer who worked with struts and spring MVC and some other action based framework, God knows how much I suffered to fix the issues or find work around for the bugs or hack even framework to get the projects successfully done, honestly I prefer not using jsf components and write everything from scratch. Using JSF in complex UI (several tabs, pages included, many checking or runtime data loading) is total failure. Writing efficient java code considering many unnecessary backing bean calls is like a joke. Involving many javascript with buggy components needs a lots of time, expertise and knowledge to resolve unknown issues. Lack of call back methods like init method (which can be used as entry point for loading and avoiding unnecessary object creation) and having a lot of conflicts between extension frame works? jar files (like orchestra and shale, tomahawk) wastes a lots of time and energy from developer team to use very basic features. You can see a lots of issue about JSF on the web which I do not want to list them, but I just want to say I don?t like jsf and I think major review is necessary before using it widely.

Posted by Shahram Niki on December 10, 2008 at 09:58 PM MST #

Hey, I read your post and I agree with a lot of it. For bookmarking pages, I got tired of trying to use other frameworks, so I wrote my own and released it as opensource. You can find it at the main site: PrettyFaces. I hope this helps if bookmarkability is part of whats keeping you from JSF!

Posted by Lincoln on January 04, 2009 at 07:08 PM MST #

Hey, I read your post and I agree with a lot of it. For bookmarking pages, I got tired of trying to use other frameworks, so I wrote my own and released it as opensource. You can find it at the main site: PrettyFaces. I hope this helps if bookmarkability is part of whats keeping you from JSF!

Posted by Lincoln on January 04, 2009 at 07:08 PM MST #

I'm not a fan of JSF either. I think its aimed at people who don't know Java/HTML very well, so it works well in a corporate/public sector environment ;).

Posted by thepigs on October 23, 2009 at 03:19 AM MDT #

I'm not a fan of JSF either. I think its aimed at people who don't know Java/HTML very well, so it works well in a corporate/public sector environment ;).

Posted by thepigs on October 23, 2009 at 03:19 AM MDT #

I am a big fan of JSF. I use it in all my projects. The author of this article is passing judgement on something which he used for three days. Again that post is from 2004. JSF is a well thought out framework, makes web development very easy and fast. JSF is as easy as Swing. There are many many tools available that make it flexible and powerful.

Posted by Arun B on November 30, 2009 at 03:24 PM MST #

I am a big fan of JSF. I use it in all my projects. The author of this article is passing judgement on something which he used for three days. Again that post is from 2004. JSF is a well thought out framework, makes web development very easy and fast. JSF is as easy as Swing. There are many many tools available that make it flexible and powerful.

Posted by Arun B on November 30, 2009 at 03:24 PM MST #

JSF is a well thought out framework
Cough...Bulls**t...cough. I spent five weeks on Mojarra JSF 1.2 specification just to create a form that has options to be selected for submission, then lists the result as 10 records per page, have a page selector, navigate to a second form and back to the first form - I can do all this in two weeks in Struts or other MVC - and this is starting anew. Five weeks to do something simple like the above - give me a break! JSF is crap...

Posted by Chuong P on November 30, 2009 at 06:09 PM MST #

10+ YEARS

TWITTER

RECENT ENTRIES

Tag Cloud

My JSF Experience