I want to display data from my database, for example products listed in my database for a customer to choose from. How do i do this with JSF? I have googled around & there seems to be a way based on a constructor method for the class the JSF will be calling. Is this right?
Is JSF the way to go with displaying the data? Or should i be using a different method?
Also how would the JSF page be associated with the bean? & how would i go about formatting the results?
Google IBM Developerworks for "JSF for nonbelievers". This is a 4-part series by Rick Hightower that, despite its age I consider to be an excellent introduction to JSF and I think you'll find it addresses your questions in detail with clear examples and illustrations.
Doing database operations in constructors doesn't work very well. Unfortunately, a JSF backing bean is not procedural, so it's hard to figure exactly where you can do your database operations. These days, I usually either do them in a "setup" method that the previous View's action processor calls, or add a @PostConstruct annotation (which requires a relatively up-to-date setup). As an alternative, I've also been known to do a "cache-style" approach, where the "get" method checks to see if the data has already been fetched, and if, not, fetches is.
As a rule, you don't want get/set methods doing logic, but this is a lesser-of-2-evils solution.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Apr 23, 2011
Thanks for getting back to me Tim (sorry it took so long),
I'm still at a loss as to whether JSF is the right strategy to implement simply showing data from the database.
At the risk of sounding like a newbie that is just looking for quick answers:
A standard method of displaying data is what i desire, whether it be JSF, JSTL or something else. Is there no standard web "shop" pattern that is always used when displaying data?
The @PostConstruct is EJB3.0 right? I understand that but where & how that would be implemented still escapes me.
The previous View's action processor would surely need to put all the data into the session context which seems a bit vulgar if you have lots of objects with parameters etc.
The "cache-style" get method approach sounds OK but slightly hackish (if that even makes sense). Even though the get / set methods would have logic in them, they would only be beans & these could be using DAO services. I have tried this in JSTL, it works to some extent but i can't seem to be able to pass variables to parameters, that's besides the point anyway (and i can always post that to the brilliant minds of code ranch :P
I'm still looking to just know i'm going down the right "standards" track.
Don't worry about the delay. I've been so busy the last 3 days I never noticed!
@PostConstruct is not EJB. I think it's one of the new standard bean annotations. It won't work in Tomcat unless you have about version 6.0.20 or later, but it's not tied to EJB. The purpose of PostConstruct is to designate a method that can be called after the constructor AND its post-construction "set" methods have executed. For example, if you want to setup a parameterized bean whose properties designate a database that is then queried to set up a table display. JSF doesn't support arguments in constructors, and there's not real guarantee that the setters would be called in the "right" order to ensure that a database query in one setter wasn't triggered before the parameters were set up in other setters. Plus, heavy logic in set/get methods is something to avoid. Using a PostConstruct method, you can have confidence that everything is there and waiting for you before you run the database query or whatever.
I use Hightower's example as a general model for table/detail view view and CRUD, so that's my "pattern". JSF does tend to force you into using session objects more than most other web frameworks do, but in JSF2 they added a View scope that automatically deletes the object once you move on to a new View.
One thing that people are over-fond of doing in JSF is that they insist on parameterizing actions. JSF is predicated on a pre-screened set of data being available when the action is fired. So the preferred way (in earlier JSF versions, almost the only way) is for the action processor to reference the bean's properties, not to pass parameters to the action. Use of bean properties is safer because the JSF lifecycle takes an all-or-nothing approach. If the values for the bean properties as entered in the View form are invalid, they don't get updated and the action doesn't get called and that's all taken care of (including error reporting) by the JSF view controller.
Joined: Apr 23, 2011
I just so happen to be running tomcat 6 so it supports @PostConstruct so that helps.
For a newbie it seems the @PostConstruct is the way to go to get things moving & get a good enough understanding. My only problem is if the bean needs to access session or request parameters how do i pass these?
Would it need a HttpServletRequest variable in the bean or is there another way?
I'm a little dubious towards using JSF because i cannot set the file extension to .jsp. I have got to grips with using basic JSTL so far but i guess it's just the newbie sticker that i still wear.
Joined: Apr 23, 2011
Quick update, I figured out how i pass the request/session variables through to the bean, well i think i have. However the @PostConstruct method doesn't seem to fire when the bean is initialised. Like i said, i'm on tomcat 6, any particular set up that i need to do?