Handling and responding to user input is the focus of this video tutorial. It takes you through the process of creating a simple xhtml page that leverages a @ManagedBean decorated POJO in order to handle user input, respond to a form submission, and dynamically display content back to the user. It's a powerful example, but you'll also find that the amount of code to get the application working is quite minimal. 

Rock Paper Scissors Anyone?

The application prototypes a little Rock-Paper-Scissors game which makes the problem you're trying to solve easy to understand, and to a certain extent, fun to code. Here's what the finished application looks like:

This tutorial picks up from where the previous tutorial left off, although you can jump right into this tutorial if you have a basic JSF 2.0 development environment working and configured, as this tutorial doesn't actually 'build off' of the previous one.

If you are following along and would like to copy the code, as opposed to laboriously typing it out by hand, you can find all of the code snippets, in the order in which they appear in the tutorial, displayed at the coderanch. It's also a great place to ask a question or two if you're running into any problems. The complete text of the tutorial is also available.

Handling of User Input with JSF 2.0 and ManagedBeans

Configuring a JavaServer Faces 2.0 Dev Environment

*******************

Catch Cameron McKenzie & Max Katz (of RichFaces Fame) at TSSJS 2011 in Las Vegas (March 16th-18th)

Oh, and by the way, Cameron McKenzie will be presenting a session at TheServerSide Java Symposium on what's new and exciting with JPA 2.0. He'll also be loitering around the various sessions being delivered by Max Katz, author of Practical RichFaces, as Mr. Katz discusses what's new with RichFaces 4.0. 

Register for TheServerSide Java Symposium 2011

Inasmuch as the frameworks like ZK are quite mature, and allow the developer to do all these things quickly and painlessly, it remains a mystery to me that people are still trying to work on JSF. Time on to move on folks.

Such cynicism? JSF is still popular, and many of the Ajax frameworks built around it make it even more appealing to potential adopters.

Having said that, we'll be running various tutorials on other Java based Web 2.0 technologies in the future.

Hi Cameron,

I thought you said you were too smart for JSP/JSF and that people who it are stupid. What happened?

Jan

Inasmuch as the frameworks like ZK are quite mature, and allow the developer to do all these things quickly and painlessly, it remains a mystery to me that people are still trying to work on JSF. Time on to move on folks.

The only mystery to me is why people like you keep plugging those alternative frameworks that only a very small minority of all Java developers seem to use.

The majority of us is not TRYING to work on JSF, we're ACTUALLY working with JSF and are being very productive with it.

Good luck messing around with Loom, the end-all be-all of web frameworks. Or no, you were talking about Wicket. Or wait... it's Zk this time...

It is the best framework around. No I am not messing with it, but actually using it.

Spreadsheet. Fisheye. Grids. Tabs. Trees.

Everything out of the box. I bet on JSF you have not even heard of many of these things. If you are not using ZK, at least 20-30% of the time that you are devoting to develoing is a waste, for ZK has everything ready for you.

Add to it the fact that if you want you can program everything in Java, without messing with XML etc, and there is no comparison between ZK and anything else.

(I have no affiliation with ZKOSS, the developer of ZK. Just a fan.)

It is the best framework around. No I am not messing with it, but actually using it.

Like others said, it's just something that a minority uses. Minorities aren't bad, but if you want to make your points accepted, you'll need to have them accepted in some standard. Just throwing random code, even if it's cool, won't help the majority of enterprise developpers, who need stability and guarantéés.

Spreadsheet. Fisheye. Grids. Tabs. Trees.

Any decent component library has that. There are a couple, actually quite good, for JSF too (Primefaces, ...). They aren't standard, but at least the building blocks are.

Everything out of the box. I bet on JSF you have not even heard of many of these things.

I think your're wrong, I envisaged almost every single possibility and went back to JSF for above mentionned reasons.

If you are not using ZK, at least 20-30% of the time that you are devoting to develoing is a waste, for ZK has everything ready for you.

You can replace ZK in this quote by about any framework or component library.

Add to it the fact that if you want you can program everything in Java, without messing with XML etc, and there is no comparison between ZK and anything else.

That's cool, but marginal.

(I have no affiliation with ZKOSS, the developer of ZK. Just a fan.)

You can't be neutral (neither can I).

I dislike JSF. I even told my boss if he insisted JSF on a project, I'll leave.

JSF always remind me EJB (1/2) -- an over-complicated standard. Luckily, it is killed by Hibernate. I hope ZK will do that and become a de-facto standard.

The bottom line is I don't belive the spec coming from Sun is a standard. To be a candidate of a standard, it must be really execellent and up to the point.

JSF always remind me EJB (1/2) -- an over-complicated standard.

And then came EJB 3 and JSF 2.

Luckily, it is killed by Hibernate.

No, hibernate is persistence and JSF is the UI part. MVC, you know? BTW, hibernate and other providers now implement JPA, the standard.

I hope ZK will do that and become a de-facto standard.

I think it won't because ZK doesn't try to be standarized (= sit around a table with different people on something, which is something else than a quick implementation of some changing ideas).

The bottom line is I don't belive the spec coming from Sun is a standard. To be a candidate of a standard, it must be really execellent and up to the point.

I think JSF 2 is. What's your definition of a standard. Standard and excellence are different things (although something that is standard *can* be excellent).

It is the best framework around. No I am not messing with it, but actually using it.

And according to the Play! fans, Play! is the best framework. What's your point really?

Spreadsheet. Fisheye. Grids. Tabs. Trees.

Everything out of the box. I bet on JSF you have not even heard of many of these things.

Nonsense, those are widely used in many JSF based applications.

OK if you give us the link to the single JSF download where all these components are available out of the box I will eat these pixels and stop singing the praises of ZK.

You guys do not seem to have done a large Web project.

<!--Session data-->

www.primefaces.org Try it and forget ZK!

http://www.primefaces.org/showcase/ui/home.jsf

The component showcase does not contain two of the components that I mentioned above.

Not to mention the ease of programming that comes with ZK.

Look, I do not want to start a religious war. I just want people to be exposed to the tools that are easy to use and make them more productive. If you give me reasons as to why JSF based xxxxfaces is better than ZK I will stop. I have given you facts. You just tell me to forget it without any factual information.

<!--Session data-->

Well the other consideration is that ZK is a pure JS framework, right? (I'm not intimate with its details). JSF is a server side framework (which, among other things can serve up JS components). 

I tried JSF several years ago, and struggled with it. This was pre-2.0.

I was specifically thwarted by the two different presentations of how it worked. One is where your backing bean had, say, a bunch of String properties and those were bound and populated, and the other was where your bean hand a bunch of controls, and you would dig the data out of the them explicitly (like TextBox1.getText() or whatever). So, it was confusing to me as to which was the preferred idiom and way to work.

My real confounding was when I was trying to get dynamic controls on the page. I was never got a good feeling on how that was pulled off, and never found a good example of it being done.

Does JSF require JS nowadays? Is it just a given for the "basic use cases"? Back in the day, .NET would require JS, since it's POST links everywhere. I don't know if JSF requires that today or not.

But there's a distinction to "requiring JS" and doing all of your development in JS, the idioms and architecture are different. So, that's certainly a reason for preferring JSF over something like ZK.

The beauty of ZK is that even a Java programmer who has never done any web programming but has had exposure to Java Swing can easily understand its event driven model and be productive very quickly.

Another important adavantage is that it is possible to write a highly interactive web application without dealing with template pages (if you are into templates you can do that too).

If the JSF proponents can provide the reasons as to why this is a bad thing, I am all ears.

I would also be glad to hear of any advantages that JSF provides over something like ZK, over and apart from the fact that a majority of the people use JSF, although I do not know the source of that statistic.

<!--Session data-->

http://www.primefaces.org/showcase/ui/home.jsf

 

The component showcase does not contain two of the components that I mentioned above.

I think it has, although with different names.

Not to mention the ease of programming that comes with ZK.

You could say just the same for Primefaces, it's oh so much easier than ZK. It's just an opinion.

Look, I do not want to start a religious war. I just want people to be exposed to the tools that are easy to use and make them more productive. If you give me reasons as to why JSF based xxxxfaces is better than ZK I will stop. I have given you facts. You just tell me to forget it without any factual information.

Don't forget it, I didn't tell you that. But if two frameworks have similar capabilities, but one is standard, I choose the standard one.

Seriously, I took a look at the samples of ZK and it does not look so easy to me with the javascript programming. I don't like programming in javascript so actually JSF 2.0 looks easier to to use. Components and properties instead of javascript programming?

HI Tomas,

    ZK is all-about programming in Java. I haven't touched Javascript since using ZK, though version 5.0 does allow you to program with Javascript on the client-side for maximum flexibility.

Obviously you did not look close enough.

You do not have to program in Javascript to be able to use ZK.

I have developed a somewhat complex site for a critial application with numerous pages, and we never had to write a single line of Javascript.

http://www.primefaces.org/showcase/ui/home.jsf

 

The component showcase does not contain two of the components that I mentioned above.

I think it has, although with different names.

Not to mention the ease of programming that comes with ZK.

You could say just the same for Primefaces, it's oh so much easier than ZK. It's just an opinion.

Look, I do not want to start a religious war. I just want people to be exposed to the tools that are easy to use and make them more productive. If you give me reasons as to why JSF based xxxxfaces is better than ZK I will stop. I have given you facts. You just tell me to forget it without any factual information.

Don't forget it, I didn't tell you that. But if two frameworks have similar capabilities, but one is standard, I choose the standard one.

It really depends on what the standard is about. I used to follow standards on EJB, and look what happened. Some of the standards just become resource hogs, both development time and run time, and often they lag behind technology innovation and best practice

John - we don't use JSF - but I just wanted to add a comment based on experience.

We've used 'minority' frameworks in the past, for better development productivity.

The single biggest issue I've seen is frameworks that become abandonware - being open source does not make up for this - even things that were popular in their time - like Struts 1 - have declining communities.

If your product has a short lifespan before rewrite, that's fine - but if you are looking at a 10 year lifespan (which is likely for a big internal system) then the projected lifespan of the technology you are using is very important.

And that is one reason why a lot of people are conservative in their technology choice - they've seen a lot of 'alternative' choices come and go.

Spreadsheet. Fisheye. Grids. Tabs. Trees.

I must have missed the announcement where all web apps need these things.

Aside from Spreadsheet and Fisheye, there are plenty of JSF component sets that provide these.

I'm not knocking ZK, but trying to say that ZK is the "best" because it has these components is a bit, um, I dunno, specious I guess.

You are missing the point altogether.

The feature that I like most about ZK is that the developers of ZK have taken great pains to integrate the libraries from various sources into their framework. Once you download ZK, all you have to do is to use their components and libraries to develop your specific application. No need to do more searches for this missing component or that library.

<!--Session data-->

 

You are missing the point altogether.

 

The feature that I like most about ZK is that the developers of ZK have taken great pains to integrate the libraries from various sources into their framework. Once you download ZK, all you have to do is to use their components and libraries to develop your specific application. No need to do more searches for this missing component or that library.

I can just say the same about Primefaces- though I know you could still miss components, in Primefaces, ZK or any libraries.

Never logged in before, but have to do it this time to support John's claim for ZK.

During my over 10 years of Java development career, I've tried most, if not all Java/Javascript UI frameworks, and there has been nothing comparable or even close to what ZK does. The #1 thing it does the best is to improve productivity, and still the UI is nice, and the code is clean and easy to maintain. I think I have over an order of magnitude in productivity improvement related to UI side, comparing to, say, GWT-based solutions. Everything just comes easy, and works intuitively, w/o those setups, gotchas, life-cycle management, etc.

Obviously, different developers have different mindset and programming preferences, and ZK may not be the one that fits your taste, but please do give it a try, and compare it with others yourself. I was able to have a full-featured web-site up with nice interactive UI, and all the backend db, middle layer connected up within a couple of hours the first time I used it. It was a real app with multiple pages and full ajax interactivity, not the standard hello-world stuff.

+1

There is one more thing I'd like to mention: ZK changes the way we do business analysis. In old days, we use drawing and, sometimes, HTML if the buget allows. But, now we can discuss with management level with the real UI and change it along with the discussion. It really impresses the decision maker and minimizes the communication efforts.