• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Application design in JSF

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am designing a pretty basic CRUD application and am struggling to come up with a good design. What I have is a view page that is essentially a table of records. I can edit each record which will take me to a new page, or I can add a new record, also a new page. I am not sure what the best architecture for such an application is. This is what I am basically thinking:

1 Session scoped bean that holds the records in a list
2 request scoped beans (1 for view, 1 for maintain which is add/edit) to have listeners, view helper methods, etc.
2 xhtml pages (1 for view, 1 for maintain)

This seems right to me, but I am not quite sure how to use 1 data bean for all my pages. It will contain a list of record objects, so when I am on the add/edit page I don’t know how to access just one of those records. Do I have a selectedRecord attribute in the session bean? Any thoughts?
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to the JavaRanch, Andrew!

I think you are a prime candidate for a very old but still very useful article from IBM DeveloperWorks. It's a 3-part series by Rick Hightower titled "JSF for non-believers". It pretty much describes your sort of situation and shows simply how to handle it.

This is a very old article, but it still works. The main changes since then is that now you can define beans with annotations as well as with faces-config.xml (faces-config overrides annotations, BTW). And JSF has added View scope.

Request scope in JSF is almost entirely useless, and especially so in cases where you are maintaining a DataModel object(s).
 
Andrew Watt
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Andrew, I read through that article. It looks like he is doing something similar to what I had above. The main difference is that he just uses 1 session scoped bean for everything. This seems messy to me for larger pages which is why I have two request scoped beans (one for view and one for add/edit) where I do as much as I can in request scoped, and 1 session bean to store the model data.

I forgot to mention that I am still stuck with pre 2.0 JSF, so I have to use request/session. Session management becomes a huge pain because I basically have to store data in the session that shouldn't be there, but I don't have much choice there. The question becomes when do I destroy those beans to ensure my data doesn't become stale.
 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What I normally do is that I keep the actual detail information in a separate JavaBean, which I can allocate before going to the detail edit page and destroy when the user returns to the table list page. JSF2 wouldn't help you anyway there, since View Scope would destroy the list backing bean when you navigated to the detail edit page. Since the detail bean is stored in the table listing bean as a property, the detail edit form does references to the detail properties like so: "#{argleBean.detail.city}".

There really isn't anything cleaner than View Scope for discarding unneeded beans. A user can bypass the destruction logic in several different ways. So while I do try to discard my session beans when people are done with them, it's more for the sake of minimizing dead storage. You are better off simply re-initializing the backing bean as part of the logic the user invokes in navigating to the list page.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic