JSP lets you do anything you want basically, that’s why it is pretty easy to start. But when you can do anything you want, it doesn’t mean you did it the correct way. JSF guides you “how” to develop your application, so some sort of at least basic training is mandatory.

There are numerous tutorials, articles and everything else on JSF on the Internet today. Additionally, there are 4-5 books available.

There are a lot more than just a few people that use JSF. I’m at JBossWorld conference in Orlando, FL right now and virtually everyone uses JSF for web development.

Yes, $495 is the price for online training offered by Exadel (the company I work for).

Max
http://mkblog.exadel.com

I’m planning to do exactly that (publish a JSF tutorial) when I’m finished with my project. I’ll let you know how that goes.

I think you missed my point about 15 pages. I have read many books and many more articles and rely on them heavily to do my work. The point was that it took 15 printed pages to explain something that could be explained in 15 *lines* of code in PHP. It’s a huge discrepancy.

Best Regards.

-Matt

they are very different frameworks.

Which is why I said “a bit like…”. There are enough similarities for this to be a reasonable statement, though.

Second, did you have any JSF training before starting to code?

Herein is my point–and you make it well. The first PHP app I wrote I was able to put together in a day without *any* previous training. I read a few examples (which are ubiquitous) online and coded my app. It’s intuitive. It’s the right tool for the job for many web applications–especially ones as simple as this. Other tools are good at this as well.

By comparison, there *is* a learning curve with JSF, as you point out and there is no good documentation I can find online. If I don’t blame the framework for being difficult, the who do I blame? I didn’t make it difficult or non-intuitive to use. My question is why punish myself using a framework that is naturally cumbersome and requires me to go through training when I can get the job done sooner (time..money…etc.) with something else?

Furthermore, the main point I made is that nobody uses JSF. Now, of course, I don’t mean literally nobody. I mean virtually nobody. In other words I’m sure there are a couple people out there who use it–maybe even in a production environment. However, I think the rest figured out it’s too much of a pain to wrestle with. Again, as I pointed out in the original post, If someone can provide me with a good tutorial that isn’t 15 pages long and in the end provides more than a silly calculator, I’d be glad to take a look and change my viewpoint. To me, the point is clear–most people aren’t willing to punish themselves to do something with a framework that virtually nobody uses–especially when so many other frameworks exist that do what I’m trying to do easier, faster, and, frankly, better.

Best Regards.

-Matt

p.s. I can understand why you would suggest training as it looks like you teach people JSF. Do you get $495 for online JSF training? That’s not a jab. I’m just curious as this could discredit the premise of my entire post. How many people sign up for such a course?

If you’re not familiar with JSF, it’s a bit like Java Struts

they are very different frameworks.

Second, did you have any JSF training before starting to code? What you described can be created in about 1 day if you actually know how to use the framework. Yes, there is a learning curve, but please don’t blame the framework before you know how to use it.

Max
http://mkblog.exadel.com

I can’t debug anything with break points as everything is compiled into a java class at run time and all I ever see are tags, not Java code. It is so far abstracted that I can’t get to the guts of it if I tried.

First, a disclosure: I’m a developer on Mojarra, Mojarra Scales, and am a member of the JSF EG. I’ve been using JSF for almost 3 years now, and really enjoy it, which led, eventually to my committer status and EG membership. Now, with that out of the way…

I’ve not found debugging to be a problem, really, though I’ll admit that some may find my approach… arcane. :) Typically what I do is this: I’ll develop in Netbeans (previously Eclipse), but use the command-line to build and deploy my artifact. In my IDE, I set break points where I need them, then attach my IDE’s debugger to my app server (GlassFish, fwiw). When I hit the context the break points are tripped and my IDE comes to the front, allowing me to do all of the normal debugging things. Eclipse even does a nice job of replacing the code on the server if I need to make a change in my app (though it’s not perfect). Using that approach, I’ve been easily able to step through my apps. I would imagine that that approach would work regardless of the framework used.

As far as debugging the tags, generally, I wouldn’t think you would need to do that (unless you’re developing custom tags, which it doesn’t sound like you’re doing). Though, if you need to, the approach above would work as well: just find the UIComponent or Renderer class for the tag in question and set your breakpoints. If by debugging the tag, you meant the point where your application and the interacts, you just need to place a break point on the method specified in the Expression Language expression (nice redundancy, huh?) and the BP will trip when JSF processes that tag, allowing you to step through that method.

I hope all that makes sense. And helps. :) I’ve written many, many apps in JSF and really do prefer it. Rick Hightower has some interesting (though admittedly debatable numbers) on JSF uptake on DZone: http://java.dzone.com/news/jsf-catches-swing-number-one-g. For what that’s worth. :)

If the design didn’t have mandated that I use JSF, I would have had this project done the same day it was assigned as I would have written it in PHP. It’s the right tool for this job, frankly.

And that might be the heart of the problem. As much as I love JSF, I’ll readily admit that it’s not the right tool for every job. In fact, I’ve written JSF apps that probably would have been easier (and quicker and smaller) in PHP, but, since we were a Java shop, that wasn’t an option (and, being small, we couldn’t afford to have an explosion of technologies), so we shoved the square peg in the round hole. For larger apps, though, I like the component-driven approach of JSF, and I think it does a great job of encapsulating the functionality of those components.

I blog quite a bit on JSF-related issues on my blog (http://blogs.steeplesoft.com - I promise I’m not here to promote my own blog. Just thought it might help ;) if you care to read any of those or ask any questions. I’m more than happy to help where I can.

-Matt

JSF is a technology that looks good on paper, but when it comes to actually using it, it stinks.

Cannot agree more. And +1 for Wicket, here’s a side-by-side comparison of Wicket and JSF with code:

http://ptrthomas.wordpress.com/2007/05/14/a-wicket-user-tries-jsf