wood burning stoves 2.0*
The moose likes JSF and the fly likes JSF best practices Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "JSF best practices" Watch "JSF best practices" New topic
Author

JSF best practices

Peter Braun
Ranch Hand

Joined: Feb 09, 2005
Posts: 57
Hi!

Do you know any book/article on JSF design and architecture? Some kind of design patterns or best practices about that how should I structure a JSF-based web application.

Thanks in advance,
Peter
Michal Glowacki
Ranch Hand

Joined: Mar 14, 2006
Posts: 114
Not exactly what you are looking for, but on this page you can find some useful articles:

http://www.jsftutorials.net/
Peter Braun
Ranch Hand

Joined: Feb 09, 2005
Posts: 57
Thanks!

Peter
Venkat Sadasivam
Ranch Hand

Joined: May 10, 2008
Posts: 139
You can also look into below page for high level information.

http://venkatsadasivam.wordpress.com/2008/05/20/jsf-best-practices/


“Any fool can write code that a computer can understand. Good programmers write code that humans can understand. ”<br>
-Martin Fowler
Peter Braun
Ranch Hand

Joined: Feb 09, 2005
Posts: 57
Thanks. The "Work around for some common issues" section is nice for me. I run into those issues. Maybe I'll try these workarounds if I'll have time.

But can you tell me about this? "Don�t create managed beans in session scope. Always create in request scope." Why do you recommend it?

P.
Venkat Sadasivam
Ranch Hand

Joined: May 10, 2008
Posts: 139
1. It is not scalable solution. Assume 100 concurrent virtual user application, session objects will consume more heap memory. You will get out of memory exception after sometime.
2. For real time data application keep the data in session will affect the data accuracy.
3. In clustered/ load balancing environment, replicating session is costly operation.

keeping session object as lean good for scalable application.
Miguel�ngel Fern�ndez
Greenhorn

Joined: Jun 08, 2007
Posts: 3
Hi.

I was looking for an article on JSF best practices or architecture design and bumped into this thread. This conversation about not implementing session managed backing beans is interesting.

About the three reasons for not implementing session backing beans I would argue the following.

I'm currently developing an application where we've had to make a lot of use of session beans because it has to deal with a few workflows. Now, Here's what we are doing. Each interface is related to a corresponding request managed backing bean which stores objects of Collection<selectItem> to build the combos, HashMap<Integer, Boolean> for checkboxes, navigation methods for the buttons and other interface related elements. Now, when an interface needs to render a collection of objects for a search, the search criteria is handed by the request managed bean to a session managed bean which in turn querys the data base and stores the result in heap memory for further use. I this querying were done directly from the request managed backing bean you would loose the ability to keep the result for further use, thus producing the overhead of having to query the data base again and again with each new request. So, of course there is a trade off to only using request managed beans. I would say that if your request managed beans involve frequently used data base queries, you might want to take another look at session managed backing beans, specially if the queries are heavy (nested or sweeping a lot of data).

I don't really know if there is a better way to develop a jsf architecture. I'm currently doing a lot of research and trying to attempt variations of the former pattern.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JSF best practices