• Post Reply Bookmark Topic Watch Topic
  • New Topic

One managed bean per xhtml ?  RSS feed

 
Divya Sudarsan
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I need to design a web page using JSF 2.0, whose home page displays 2 links. The 2 links point to 2 different xhtmls. These 2 xhtmls are forms with controls which take in user input and each does something different (by accessing DB). In future we plan to add more hyperlinks to the home page in addition to these 2.

I have the following questions :

1. Generally do we need one managed bean class compulsoruly for each hyperlink that I add to the home page (in this case, at present 2) ?

2. Is there any way to arrange all these now in a particular design pattern so that adding additional hyperlinks (which perform entirely different functions) in future would be easier ?

3. Can you point me to some sample applications in the web with the similar requirement ? Or can you just let me know the flow e.g. Link1.xhtml-->Link1Managedbean-->Link1DAO . Since I will be adding more completely different links in future, is there someway to have a generic managedbean or a business delegate class? Please guide

Thanks a ton for the help. I am totally new to JSF 2.0
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, the first thing you need to do is fix your display name. No fix, no answer.

We don't have many rules here at the JavaRanch, but we do insist that you use your Real Name and not some sort of "handle" or obvious alias. If you're not sure about this, see
http://www.javaranch.com/name.jsp .

 
Divya Sudarsan
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Display name fixed
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you. Welcome to the Ranch, Divya!

Technically, you do not link to "xhtmls", you link URLs, and the URLs invoke Views. The "xhtmls" are View Template resources which define the prototypes of the Views in View Definition Language. The JSF FacesServlet in combination with its Facelets subsystem decodes the URLs in order to locate the appropriate xhtml resource to compile into an HTML View, subject to certain qualifications.

There is no requirement for a 1-to-1 template-to-backing-bean correspondence. Multiple Views may share a single bean, one view may employ multiple beans. It's full-on many-to-many. Whatever works best for the task at hand. Nor are the backing beans all required to be of the same scope. I often use application-scope beans to hold common menu lists, for example.

I generally laugh at people's attempts to make a common framework for backing beans, as JSF already is providing that function. When working with complex systems, I usually do use the Spring Framework to inject persistency-service objects into my backing beans. These objects are not DAOs, however, since they handle the transactionally-managed business functionality of connected sets of tables. The actual table-level DAOs are then injected (via Spring) into those objects. In extreme cases, where I have major business functionality that is not part of persistent store transactions, I'll also let Spring inject business processing beans into my backing beans. The actual JSF backing beans are primarily MVC Model objects, so I try to use them primarily for the UI-related functions rather than put a lot of business logic in them.
 
Divya Sudarsan
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the reply.

what would you suggest for my situation which I have described in my initial post ? It is just a simple application with 2 links on the home page each doing different things. Can I have something like

Link1.xhtml-->Link1ManagedBean (Controller)-->BusinessLogicClass-->DatabaseHelper (Hibernate)

Link2.xhtml-->Link2ManagedBean (which calls methods on businesslogic class)-->BusinessLogicClass (Same as above)--> same DatabseHelper as above.

In future when somebosy else needs to add another Link3, he just needs to create his own xhtml, his own managed bean, and place his business logic in existing Business logic class, and reuse the Database helper/add new methods if required. Please let me know if this is the efficient way to design.


We are not allowed to use Spring in the current application. For DB, we need to use Hibernate. Any alternatives are also welcome
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nothing wrong with it. There's no single solution, just solutions that work well for you.

I find Spring to be extremely cost-effective. Since it's based on Inversion of Control (IoC) just like JSF is, it can wire together utility components like business objects and the Hibernate services without breaking the paradigm because you'd otherwise be hard-wiring service locators or actual services into the JSF backing beans. Plus it encourages a modularity of construction that makes things much easier to test. My major web project run extensive unit tests as part of the production build process. In large part because I had trouble getting clients to pay me when side-effect bugs slipped into production and got discovered by end-users.

Not everyone loves Spring, though. Then again, some of our bartenders don't love JSF, either. To each their own.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!