• Post Reply Bookmark Topic Watch Topic
  • New Topic

Basic JSF question (Backing Bean- Managed Bean flow)  RSS feed

 
Aditya Kumar
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I have not much worked on JSF and thus this doubt may be a mere basic one. Pardon me for that.

I am often confused with the backing bean - managed bean concept. I do understand that every backing bean is a managed bean too. But if JSF is a component driven framework, is the managed bean related to the UI component or that page? Let me ask this via the Employee - Department example:

There's a CreateEmployee page. User enters employee entity data (name, etc) in the relevant fields. There must be a backing bean there? Say, CreateEmployee Backing bean that is unique to the page? (Or just an employee backing bean that is common?) But department is another entity and the Department dropdown is to be populated via a DB call. Will I need to associate the Department dropdown with a Department managed bean (that will in turn go ahead and query the DB via a SLSB?) So in this case, we have an Employee backing bean and a Department Managed bean? Also - if it is right, then will the Backing bean be responsible for calling the Department managed bean? (createEmployee.jsp->FacesServlet->Employee(BackingBean)->Department(ManagedBean)) -- Is this legitimate?

Or have I got this all wrong?

Aditya

 
K. Tsang
Bartender
Posts: 3648
16
Firefox Browser Java Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JSF follows a MVC pattern. The controller is the FacesServlet. The managed bean is the model and the jsf/jsp pages are the views.

IMO, every view page should have its own manged bean that tells what to load for dropbox, what to show etc. This makes the clearer to understand the flow.

Using your example: employee and department will be entities (regular POJOs). The CreateEmployee will be the managed bean that uses Employee and/or Department as needed.

The managed bean will have all those action methods for button clicks, dropbox change value etc.

Hope this helps.
 
Aditya Kumar
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tsang,
Thanks for replying.
Does it mean that If I have a JSP interacting with two managed beans (EmployeeBean for saving Employee data and DepartmentBean for retrieving Department data) it is completely wrong?

Edit:Further to add, does it also mean, since you said that every jsp should have its own managed bean, that I can't have a single managed bean doing the jobs for all Employee related pages? For example, in my case the employeeManagedBean can't call a department managed bean (not entity bean POJOs - they are different i know) to fetch department data?
Aditya
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As Tsang as said, a Backing Bean is a Model. Some people think that because they can contain action methods and AJAX listeners, that makes them Controllers, but that's not true, since a Controller is a component that syncs the data in the Model and the View, and action/ajax methods are business logic and not part of the actual MVC paradigm. All of the Controller functionality in JSF comes from either the FacesServlet or the pre-written tag processors.

A JSF Managed Bean is simply a POJO that JSF instantiates and initializes on-demand and stores in one of the J2EE scope collections (application, session or request). View scope is actually a special management of session scope. The most common way to get JSF to instantiate a Managed Bean is to request a View that needs that bean, although JSF will also cascade and instantiate any beans referenced by Managed Properties.

There's a little confusion also about Models. JSF apps often have MVC (UI) Models and persistence (Object) Models. People often try to make the ORM Object Models do duty as UI Models, but there are limits to how JSF can initialize objects that make that concept mostly infeasible. Plus, the UI often needs functionality that an ORM Model object doesn't have.

Definitely the most common case is that Views and Backing Beans are associated 1-to-1, but there are times when it's more useful to have multiple Views working off the same Model object - for example, a simple Wizard workflow. And there are times when it's useful to have one View that works on multiple Models. However, the 1-to-1 is what you should use when in doubt. Even in a Wizard sequence, you might not want one massive doi-everything bean for all the views; it might work better for the Views to each have a View-specific bean and have them share a bean for the accumulated workflow as injected Managed Properties.
 
Aditya Kumar
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim,

Thank you for such an elaborate answer.
My main doubt is this - I can go with a backing bean one-to-one with the JSPs but then is it alright for the BackingBean to fetch data from other managed beans?
In other words, then, does this sound OK?


OR - can I chuck the idea of having managed beans based on mirroring the business requirements and entities (EmployeeBean, DepartmentBean) and let the backing bean (say, UpdateEmployeeBean) interact directly with the Business Delegate/SLSB?

I will really appreciate your prompt response!
[updated: with image instead of text code which wasnt properly displayed earlier]
Thank you, again.
Aditya
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can definitely inject Managed Beans into each other. A common case I use is where I have a list view and a detail display/edit view. I keep a separate bean for each View, but the detail bean is injected into the bean that manages the list view so that when someone clicks on a row in the table, I can populate the injected detail bean from action logic in the list view before having the action navigate to detail edit. For an example, google for "JSF for non-believers" by Richard Hightower.

As I said earlier, ORM model beans are not suitable in most cases for using as JSF managed beans, directly or indirectly. JSF cannot, for example, do a retrieval by key of the proper object instance, since the JSF Bean Manager cannot invoke factories, finders, or constructors with arguments. However, by integrating the Spring Framework into JSF, you can do all sorts of things with the ORM layer.
 
Aditya Kumar
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim,

My question then is - do I need to do that (inject managed beans into each other)? Going back to the Employee - Department example, may I ask what do you think is the right way? All I need is that the department data be fetched from the department table in a "UpdateEmployee.jsp" page and that the employee data is saved on "submit". I would just like to know what could be the ideal flow here 1) for fetching the department data and 2) for saving the employee entity?

Of course, I will also need to refer to the book you mentioned and I will do so. But since we are at it, I thought of asking it out here.

Thanks much!
aditya
 
K. Tsang
Bartender
Posts: 3648
16
Firefox Browser Java Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For your employee-department example suppose:
* Department has many employee (one-to-many relationship)
* Employee POJO/table = empId, empName, deptId (where deptId links to the Department POJO/table)
* Deparment POJO/table = deptId, deptName, empCount
* create/update employee view page specifies the department name (from dropdown or similar hence has deptId)
* Employee POJO has method "save" persisting to DB
* Department POJO has method "save" persisting to DB
* CreateEmployee managed bean maps to create employee view

Now when user create/update employee (eg save action in CreateEmployee):
1) get the necessary parameters from the view
2) get the Department info (eg empCount)
3) new Employee and call Employee#save method
4) increment Department's empCount and call Department#save method

Now the confusing part is where to put those business logic for persisting to DB. In the managed bean itself or the entity POJO? If using the ORM philosophy/concept, then I would recommend putting in the POJO.

The logic for the methods in the managed bean should be short and to the point.
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
They're ALL POJOs. Just different flavors.

An ORM Entity Bean (POJO) should have no business logic in it at all.

An ideal JSF Model Bean (POJO) shouldn't have business logic either, just display-related logic and calls out to the business functions. Although I often cheat if the business logic is simple.

An idealized system would therefore have a third type of beans for the business logic and they would handle the interface between the UI and the persistence. I do this when the business logic is complex or I want something I can re-use in other (non-JSF) applications.

Most of my JSF apps have 2 persistence layers. One for the raw table find-and-CRUD functions (DAO) and one layer for the business persistence service (since often a collection of different tables is processed as a unit). The actual ORM Entity objects form a third layer, but they are passive data transfer objects, not active logic. If you're using EJBs, the persistence layer(s) may include Session EJBs.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!