Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Class as attribute of another class, displaying values  RSS feed

 
Alessio Belcastro
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone,
I'm using JSF 1.2. I have this problem: I have two java classes mapped with JPA (so I have the corresponding tables in the DB) called Books and Authors. Authors is in a relationship OneToMany with Books, so a book can have only one author and an author can be associated to many books. The important thing about that is that "Books" has the attribute "Authors" inside, to reference it.
When I go into the "details" page (jsp) that displays one of the books, I would like to view the corresponding author (his CodFisc attribute), but I can't make it work. In the "Books" table on the DB the CodFisc attribute (the foreign key referencing the table "authors") is set correctly, I just have to show it someway...

I'm posting you the code (just the useful things, if I forgot something tell me, please):




in the JSP I put:

In another page the call is done in this way:


It doesn't give me errors, just doesn't show that attribute (the others are shown). Maybe that, because the attribute "authors" of "books" is a class, it's not so easy as I thought calling its attributes...
I've looked for this anywhere but I couldn't find a solution (or maybe it was to complicated to understand for me, I'm not very pro)

Thank you!
 
Tim Holloway
Bartender
Posts: 18661
71
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's not always easy to make snap diagnoses from a quick look at the screen, but it looks like the most important details of all are lacking. The actual backing bean itself and the set/get property methods of the entity bean.

One thing I should mention is that if you're attempting to use an Entity as a backing bean, don't. That strategy doesn't work very well, since JSF isn't flexible enough to vary which instance of the entity you're referencing. So you should construct a backing bean that exposes the entity instance as a property, instead. I'm going to invent one for illustrative purposes and call it "bookInfo", where the "BookInfo" class exposes the property named "author", which is the author that we're currently interested in. So, to get a tabular display of all the books for that author, you'd setup something like this:



Assuming that the one-to-many property of Author for books was named "books".

Actually, I get the impression that you're attempting to go in reverse from book to author, but since most books have only one author (and you did say one-to-many!) I thought that this would be a more useful example.
 
Alessio Belcastro
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:
One thing I should mention is that if you're attempting to use an Entity as a backing bean, don't. That strategy doesn't work very well, since JSF isn't flexible enough to vary which instance of the entity you're referencing.

Ah. Ok! That actually was what I was trying to do...good to know!
I've implemented the bean as you said and it's succesfully "keeping" the authors right now! (Thanks for putting the more complicated example, it's perfect because I'll have to use that one too )

There's just one thing that I can't still understand; in your example the property "author" shouldn't be a list? Because bookInfo will be one single bean that will have to grab all the authors (if I have understood well).

In bookInfo I've put the property (and set it when needed)
but when I enter in the page "details" of books (which doesn't have a datagrid)



obviously he doesn't know which author he must pick for the current book. Am I misunderstanding something? Or maybe I have to use a query?

Thank you for taking time to help me!
 
Tim Holloway
Bartender
Posts: 18661
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, I did something wrong there. Instead of


the preferable way to do it would be:


Where "books" is a property of BookInfo that returns a DataModel object that was constructed to wrap the author.books List. Datatables shouldn't attempt to use collections directly as their model objects, since the DataModel is required to support the cursor functions of DataTable.

I'm presuming that you only want to view one author at a time here. If you want nested tables (books within authors), it gets messier and I don't think you want to tackle that just yet. So no, you don't need a list of Authors, since you can make BookInfo fetch the author you want from JPA when you prep the View (actually the View Model) for display.

When you're working with tabular data, the dataTable is the weapon of choice. Too many people try to do this stuff by "programming" the View, they way they did in the Good Old Days. JSF is a pure MVC implementation and that means that the View is a template, not logic. When you have a 2-dimensional tabular display, treat it as a 2-dimensional tabular display, not as a loop through a bunch of rows. Whether the displayed table was constructed by serial iteration or parallel processing is totally immaterial to the end user, so why code in artificial constraints? Besides, the dataTable has support for server-side detection of what row was selected when you fire its command button or link. So you don't need to code a parameter on the View to tell it.>
 
Alessio Belcastro
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That was very useful, it's working now Thank you so much!!! Even for the explanation, it was interesting

Another problem I had was this:



I had to change it into



so that I could access to the name of the author (that obviously was in the other bean)
 
Tim Holloway
Bartender
Posts: 18661
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You probably are working with detached objects, then.

A lot of people cheat and plug in a component that keeps the object attached throughout the whole request, but I don't like that idea. To me, it's sloppy. Among other things, it means that something could modify the data somewhere else and you wouldn't know it. I prefer to compartmentalize: UI interface and general business logic (detached). Transactional business logic (attached), and low-level persistence logic (finders, save, update - also attached).

One problem with using detached objects is what you ran into. You can eager-fetch the dependencies, but if you're not careful, you can end up sucking almost the entire database into RAM. Multiple times. So my transactional business logic generally incorporates the idea of "working sets", which are related objects treated as a unit, with the dependencies force-fetched, leaving the actual model set for Lazy fetching.
 
Alessio Belcastro
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Uh, sorry for answering so late

Tim Holloway wrote:You probably are working with detached objects, then.
A lot of people cheat and plug in a component that keeps the object attached throughout the whole request, but I don't like that idea. To me, it's sloppy. Among other things, it means that something could modify the data somewhere else and you wouldn't know it. I prefer to compartmentalize: UI interface and general business logic (detached). Transactional business logic (attached), and low-level persistence logic (finders, save, update - also attached).

Yes, even if not for my choice...but I understand your arguments, in fact online I found a lot of code examples that open and close the transactions anytime they perform an operation!


Tim Holloway wrote:One problem with using detached objects is what you ran into. You can eager-fetch the dependencies, but if you're not careful, you can end up sucking almost the entire database into RAM. Multiple times. So my transactional business logic generally incorporates the idea of "working sets", which are related objects treated as a unit, with the dependencies force-fetched, leaving the actual model set for Lazy fetching.

Yes, I will have to pay attention about that (fortunately at the moment I'm using very small tables). I'll try to build a structure that uses lazy fetching, because I think that sooner or later I'll need that

Thanks again!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!