JSF 2.0 Dependency injection problem
mehmet osman
Greenhorn
Posts: 2
posted 5 years ago
Hello i have just started learning jsf 2.0 and kind of disappointed with the lack of documents and tutorials.
Anyway, i want to use an entity bean and a controller separetely in JSF 2.0 just like in Struts2 but i am not sure it is possible here.
In my example i want to bind the EntityBean.java class to a form, but use some other classes action for business logic.
Is this possible? Thanks for your help in advance.
By the way could anyone point me to the direction of a good jsf2 book ?
Here is my code
helloworld.xhtml
HelloBean.java
EntitiyBean.java
Anyway, i want to use an entity bean and a controller separetely in JSF 2.0 just like in Struts2 but i am not sure it is possible here.
In my example i want to bind the EntityBean.java class to a form, but use some other classes action for business logic.
Is this possible? Thanks for your help in advance.
By the way could anyone point me to the direction of a good jsf2 book ?
Here is my code
helloworld.xhtml
HelloBean.java
EntitiyBean.java
posted 5 years ago
In JSF, you don't actually often write Controller logic in the strict MVC sense. Most of JSF's controllers are pre-supplied in the FacesServlet and the JSF tags. The action methods are really more business methods than controllers.
It's perfectly legal to reference more than one backing bean (Model object) in a JSF View, and there's no reason why you couldn't have some be pure Model objects and others be pure Logic objects. It's generally not done that way in common practice. One of the big complaints that people what about Struts was that it took too many files to do things, so, if anything, we tend to be the opposite in JSF. Still, there are some cases where a segregated architecture is useful, especially if you are attempting to use an externally-supplied POJO directly as a backing bean.
It's often awkward to use a POJO directly as a Model, however, so a lot of backing beans are façades for POJOs that add JSF model characteristics and action processors to the mix.
One thing you will discover quickly in JSF, however, is that Request scope is usually more trouble than it's worth. That's because data "evaporates" when postbacks are done.
It's perfectly legal to reference more than one backing bean (Model object) in a JSF View, and there's no reason why you couldn't have some be pure Model objects and others be pure Logic objects. It's generally not done that way in common practice. One of the big complaints that people what about Struts was that it took too many files to do things, so, if anything, we tend to be the opposite in JSF. Still, there are some cases where a segregated architecture is useful, especially if you are attempting to use an externally-supplied POJO directly as a backing bean.
It's often awkward to use a POJO directly as a Model, however, so a lot of backing beans are façades for POJOs that add JSF model characteristics and action processors to the mix.
One thing you will discover quickly in JSF, however, is that Request scope is usually more trouble than it's worth. That's because data "evaporates" when postbacks are done.
An IDE is no substitute for an Intelligent Developer.
Rafael Fontoura
Greenhorn
Posts: 11
posted 5 years ago
Well, it's possible like Tim said. If I was making a decision, I use the managed bean as a controller. If you don't plan to split controller and business logic, do it like Tim said: put the controller (managed bean) doing the business logic to manage the model and controlling the application flow. If you choose to split, the managed bean can be used as the controller only, choosing the direction to follow (go to a page, business logic class, retrieve or persist data, show message to user).
I think using a managed bean as an entity bean is awkward, too. Are you using a DBMS to persist data? If yes, can't you use JPA or Hibernate? You could use @javax.persistence.EntityBean to map a relational database table to your entity bean.
I recently bought the book Core JavaServer Faces 3rd. Edition. Read it a little and seems to be a very good book.
mehmet osman wrote:
Anyway, i want to use an entity bean and a controller separetely in JSF 2.0 just like in Struts2 but i am not sure it is possible here.
Well, it's possible like Tim said. If I was making a decision, I use the managed bean as a controller. If you don't plan to split controller and business logic, do it like Tim said: put the controller (managed bean) doing the business logic to manage the model and controlling the application flow. If you choose to split, the managed bean can be used as the controller only, choosing the direction to follow (go to a page, business logic class, retrieve or persist data, show message to user).
I think using a managed bean as an entity bean is awkward, too. Are you using a DBMS to persist data? If yes, can't you use JPA or Hibernate? You could use @javax.persistence.EntityBean to map a relational database table to your entity bean.
mehmet osman wrote:By the way could anyone point me to the direction of a good jsf2 book ?
I recently bought the book Core JavaServer Faces 3rd. Edition. Read it a little and seems to be a very good book.
SCJP 5.0 | SCWCD 5
posted 5 years ago
Sorry. I'm going to be pedantic here.
Backing beans are not Controllers in the MVC sense. An MVC Controller is a component that when supplied with a View and a Model causes changes in the Model to be reflected in the View and changes in the View to be reflected in the Model.
A JSF Backing bean is a Model, although it has some non-MVC characteristics as well - most notably the Action methods, which serve as the interface between the MVC Model and the business logic. The closest thing to actual "Controller" characteristics that backing beans provide are the Listeners, and those should be used sparingly.
Backing beans are not Controllers in the MVC sense. An MVC Controller is a component that when supplied with a View and a Model causes changes in the Model to be reflected in the View and changes in the View to be reflected in the Model.
A JSF Backing bean is a Model, although it has some non-MVC characteristics as well - most notably the Action methods, which serve as the interface between the MVC Model and the business logic. The closest thing to actual "Controller" characteristics that backing beans provide are the Listeners, and those should be used sparingly.
An IDE is no substitute for an Intelligent Developer.
