1,I am in a very confusion.I am not able to recognize what methods (binding,action,validation,actionlistener)a backing bean(i.e bean for my jsp page) would contain and what methods my Managed bean generated by me contain(that i can add )?.
2.Why do you make ordinary bean as managed bean?
3.is it required to add entry in faces config for every faces jsp page?(means is entry necessory?)
There are lots of questions here. But, your backing bean and your managed bean is really the same thing, right? I have a feeling a devleopment tool might be creating backing beans for you, blurring the lines. But really, it's all the same.
What do you have on a form that you want to pass to the server and process? That's what goes in your managed bean. It's that simple! Anything that needs to get to the server, and potentially be validated prior to getting to the server, goes in a backing bean.
>>Why do you make ordinary bean as managed bean?
It depends on what you mean by ordinary bean.
Keep your backing beans simple. They just have properties that represent data on the client screen, the appropriate setters and getters, and of course, so 'do' action methods. Are they an ordinary bean? Well, I wouldn't say they were POJOs, but often the data in a backing bean is copied to a POJO before being passed to a deeper level of your application for processing or storage.
>>is it required to add entry in faces config for every faces jsp page
I know what you're getting at. It's all that navigation stuff, right? Yeah, I know, it seems onerous. But if you want to have Java ServerFaces help you with page navigation and such things, you're going to need alot of entries in your faces-config.xml file. Will every JSP go in there? Well, probably not fragments, or directly accessed pages, so there are exceptions, but for the most part, which is what I think you're asking, you'll have every JSP in there.
That gets deeper into the neat stuff that JSF does. Binding helps match data in JSP pages to Java classes, actions are your methods on the server that process data, validation provides routines for doing just that - validating data before it gets processed by your actions, and actionListeners are cool ways of making a web application more event based, so you can listen to drop down boxes being selected and stuff, as opposed to typical web applications that can only respond to submit buttons that deliver a form to the server.
JSF have many neat features. It can seem overwhelming, but if you tackle it all one piece at a time, eventually it will all make sense.
Joined: May 20, 2009
Thanks a lot Cameron for your reply.
I am using Rad 6 which generates backing beans for me.(beans for my JSP page).
My question is which method goes where.?Means is there any restriction that my action,action Listener,validation should go inside the backing beans for my jsp page or in Managed beans.?
And the below entry for jsp page is required for every jsp?
Have you seen our rules on display names? We're not real picky about most things on the JavaRanch, but we do insist on this one, since despite the moth-eaten moose logo, we do attempt to masquerade as professionals. http://www.javaranch.com/name.jsp
Managed/backing beans are not magic. They're simple JavaBeans, so they can contain any methods and properties you like, and it was an explicit design goal when JSF was created that they should never be required to implement ANY methods or properties just to be JSF-compliant.
In fact, I like to say that the best JSF beans don't even use JSF, although that's stretching it a little.
The management facility doesn't refer to the bean, it refers to the fact that the JSF framework will construct the bean automatically and wire in other beans as specified in the faces-config.xml file on demand. Backing Beans are simply beans that are referenced by JSF pages. But, like I said, in the end they're still just POJOs.
An IDE is no substitute for an Intelligent Developer.
Joined: May 20, 2009
Thanks tim for your advice and your answer.I am very new to javaranch so dint know about naming and will follow the same.