aspose file tools*
The moose likes JSF and the fly likes Application design in JSF Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "Application design in JSF" Watch "Application design in JSF" New topic
Author

Application design in JSF

Andrew Watt
Greenhorn

Joined: Apr 16, 2013
Posts: 2
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?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16012
    
  19

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).


Customer surveys are for companies who didn't pay proper attention to begin with.
Andrew Watt
Greenhorn

Joined: Apr 16, 2013
Posts: 2
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

Joined: Jun 25, 2001
Posts: 16012
    
  19

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Application design in JSF