Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Issue with understanding EJB functionality as it relates to Primefaces/JPA/JTA

 
Randy Maddocks
Ranch Hand
Posts: 78
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello, hopefully I have the right forum for this, but please feel free to move it to another, if necessary.

I am at wit's end on understanding how to do something on a web app I am developing. At the risk of misuse of terminology here is what I am trying to do:

First, bit of background info: I am using NetBeans 8.0, Primefaces 4.0, JPA 2.0 (using @NamedQuery query methodology), JTA, JDK 1.7.0_71, running on JBoss EAP 6.2, against an Oracle database. I used the NetBeans feature to have it build a CRUD application, so any ManagedBean, JSF pages, etc. . .were built for me (I have just been tweaking as necessary for the web app requirements).

The particular part of the web app I am struggling with involves a JSF page that prompts users to enter some data (in a selectOneMenu and a couple of inputText components). I want to check the data entered and then create a NamedQuery to extract the data from the database and display it in a dataTable. I already have an Entity class that maps to the database, along with a controller and facade classes to handle the data checking and persisting, etc. . ., as well as a JSF form (bound to that Entity bean) that displays the data, and which allows users to enter and submit data (which works well). But the JSF page where the selectOneMenu and inputText components are located is different than the aforementioned JSF form, and I don't know if I can use the existing controller and facade classes to perform the necessary data checking in order to get the data from the database and populate the dataTable. Or, whether I have to create new controller and facade classes to do that.

I sincerely hope this does not sound confusing. I have not posted code as I wanted to just put this summary out there first. If posting code will help I will gladly do so. Again, I am sure this is due to my lack of understanding the whole concept of JSF/JPA functionality. I do acknowledge that I have found and consulted several excellent articles (including ones on this site!), but for some reason I still have some confusion around this.

Any help would be greatly appreciated. Thank you!
 
K. Tsang
Bartender
Posts: 3585
16
Android Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First JSF terminology there is not really a controller you are programming. The controller is that FacesServlet thing, not something you create. The things you create are really models.

Anyway so your problem is how to get info from 2 different pages (forms) (given these 2 pages use different models)?

1/ Are these 2 pages related? Hence you can say store the first page data into session or some variable for the second page
2/ Why not combine these 2 pages/forms into 1 page? Hence you can access everything in one model
3/ Doesn't composition (has-a) concept work?
 
Randy Maddocks
Ranch Hand
Posts: 78
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi K. Tsang,

Thank you very much for your reply, and for clarifying about controllers!!

I actually ended up following your Option #2 - combining the pages into 1 page. I guess part of my confusion was around being able to do everything in one model - I wasn't sure to what extent I could do that. Anyway, the problem is now resolved. Thank you once again for your reply!

Cheers!
 
K. Tsang
Bartender
Posts: 3585
16
Android Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Glad my reply helped.
 
Tim Holloway
Saloon Keeper
Posts: 18367
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ah, our esteemed Mr. Tsang has learned his lessons well!

It's true, JSF is a relatively pure implementation of the Model/View/Controller paradigm. The Models are backing beans (POJOs), the Views are defined in templates, and the Controllers are pre-supplied - you don't write Controllers in JSF.

One thing that confuses a lot of people (besides thinking that the Action Methods in backing beans are Controller methods, and they aren't), is that in a complex webapp, you actually have 2 types of Model object.

The JSF backing bean is a UI (MVC) Model.

The persistence objects (Entity EJBs) are Data Object Model objects.

Both JSF backing beans and ORM persistence Model objects are POJOs, which means that in certain very rare cases, you can have a dual-use object which serves as both a persistable object and as a Managed Bean.

But those are VERY rare cases, since JSF cannot lookup persistent objects by key, only instantiate via no-argument constructors.

You can make an entity object be a contained property of a backing bean, since the backing bean's support logic can have CRUD methods in it, thus making it possible to do a "find" for an existing object. So the Entity object "Person" won't work as a backing bean, but an "EmployeeToEdit" backing bean might have a "person" property that would be a fetched EJB corresponding to the person to edit.



I usually don't use EJBs as such these days - I use Hibernate JPA. My "standard" JSF web application uses JSF to instantiate and wire the Managed Beans and Spring Framework to instantiate and wire support beans such as the persistent Service objects and DAOs. So usually something like this:


The Business logic MAY fold into the Backing bean if it's simple enough, and not worthy of re-use. The Persistent Services manage "working sets" of persistent objects. Meaning, for example, a parent and set(s) of children treated as a transactional unit. The DAO Services do the table-level finder and CRUD operations for the Persistent Services, and since the Persistent Services are transactional, the necessary DAOs all operate within a single persistent service transaction. Found Object Models are presented as working sets and passed back up to the Business or Backing Bean layers, since, as I said, they cannot be actual backing beans, but they can serve as property objects of backing beans. I don't leave the EntityManager connected at that level, however. Once you've exited a Persistent Service, the objects are detached. Not everyone does this, but I consider it more resource-efficient and less likely to result in inexplicable random object changes.

Obviously this scheme does work with EJBs, too. Just make the Persistent Services and DAOs be Session Beans.
 
Randy Maddocks
Ranch Hand
Posts: 78
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Many thanks for the explanation Tim! I have filed that info away as I am sure I will be referring to it multiple times! Also, again, thanks to K. Tsang for his helpful reply. Cheers!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic