Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Primefaces OrderList not showing data.  RSS feed

 
Tim Resh
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello, I have a primefaces orderlist that does not seem to work and the primeface site is not helping me. I have debugged the code and I do have 7 configValuesEntities to display. Any help would be great as apparently orderlist is not used much. Here is my code.



and my Bean

 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Unfortunately, "does not seem to work" doesn't tell us what it does seem to do. We need more information.

Outside of that, NetBeans is wrong JSF Backing beans are not Controllers, they are Models

Also, you're obtaining 2 EntityManagers and that may be a problem, since when you do that you can end up with transactions that are fractured across managers. Usually one EntityManager is sufficient (unless you're talking to 2 different databases). Ideally, also, you shouldn't be having to go fetch them, since JSF is all about Inversion of Control and therefore something should be injecting them. I'm presuming that you're not using EJBs, so I recommend the Spring JPA ORM framework for that. It's what I use.

 
Tim Resh
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim, I am getting no list of data just the surrounding box plus the controls for the orderlist. typesvaluesController.configValuesEntities does have 7 entries but does not display them. As for the other comments you are right I am not using EJB's. I am using JPA with Hibernate but I have never tried Spring. Do you know of any good examples of Spring JPA ORM and injecting them in a JSF backing bean?

I use a POJO maker and then add my annotations for JPA. I prefer annotations over xml configuration as it means less possible mistakes on my part.

Yes, I now know they are Models as you have pointed out before, unfortunately I cannot change Netbeans. I guess I could rename them, but I have a ebook called Primefaces Beginners Guide and they even call the JSF backing beans controllers, go figure.

I really appreciate all the help you give.

Thanks
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
2 things that trigger automatic tirades from me are Do-It-Yourself login/security systems and NetBean's sloppy terminology. Sorry if it gets old, but there are important reasons why I keep blindly repeating this stuff. In the case of the "Controller" issue, it's not just that mis-naming the generated classes causes people to wrongly perceive how JSF is working, there are people who try to actually make backing beans work as Controllers, which denies them the simplicity of how JSF really does work (and ultimately leads to less reliable, more expensive "solutions"). So please forgive me.

Anyway, I have lots of examples of how to use Spring JPA with JSF. Unfortunately, most of them are in proprietary code.

Just a general overview, though. First, my standard architecture for this approach is that I have 2 persistence logic tiers plus the entity beans. The upper tier ties to the app's business logic and handles transactions involving multiple tables and other complex issues. The lower tier is my DAOs, which mostly have the basic find/CRUD functions of a single table per DAO (although in some cases, a parent/child table relationship gets both tables in one DAO).

My upper-tier persistence ("service") modules provided the demarcation between detached and transactional entities. I don't like the common practice of holding a database connection over from the business logic to the display rendering services - too many opportunities to zap something accidentally - so I invoke a persistence-service method to fetch a "working set" of detached entities that the business and display functions can use, and then if/when I'm ready to update them, I invoke a "save" method in the persistence-service tier that merges the changes with the actual ORM system and - where applicable - returns a new copy of the working-set objects (ORMs have a habit of returning objects that are equal, but not identical when merged).

There's a Spring-JSF bridge functionaility that allows me to code EL references to any Spring-managed bean, and I use that to inject the persistence service components into my JSF backing beans so I don't have to go out and fetch them. The persistence services and DAO classes carry a Spring annotation of "@Repository", which tells Spring that I'll be using them that way. They also carry the @Transactional annotation, because, as I said, the persistence service methods each comprise one database transaction. DAO's run under the services method transaction context.

In practice, this makes for a very tidy arrangement that's easy to implement, easy to understand, and easy to maintain.



Now on to your specific problem. You essentially need to determine whether the fault is in your not fetching the data or in PrimeFaces not rendering it once it's fetched. I haven't worked with PrimeFaces in a while, so I hope someone who has some PrimeFaces expertise will read this thread and offer some advice. I know at least one shop in my own town that's stuffed with PrimeFaces workers, but alas, I'm not considered worthy to associate with them and I don't know of any of them hanging out on the Ranch.

Be that as it may, one thing I've learned is that @PostConstruct isn't as wonderful as it would appear. It's only invoked once, right after the bean is constructed (hence the name), and in JSF, sometimes this is not often enough. Instead of using PostConstruct methods, I've found that a more productive approach is to do "load-on-demand". Meaning that I do the actual loading of the data as a sub-function of the data's property-get method. For performance reasons, I cache this data (since "get" methods can easily be invoked 5-6 times in a single request). Then, if I need a fresh copy, I simply null the cache so that the next "get" triggers a reload. It's not as straightforward as a @PostConstruct, I suppose, but it's more flexible.
 
Tim Resh
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Tim, I agree with all that you have said. I try to keep display and screen handling with detached entities and just merge them at the DAO to avoid DB and Entity locks. The extra layer avoids many problems in a multi user webapp.

I will look into the Spring Repository features you have described. I have never used Spring so this will give me the opportunity to try it out.

As for the Primefaces problem with orderlist, I have not been successful in making it work so I am switching to a dataTable since I can display additional info per row and allow sorting by columns. I thought orderlist would have been neat way for the user to order my list but no joy.

Once again Thanks for all your input.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!