On 12/19/06, Behrang Saeedzadeh <[EMAIL PROTECTED]> wrote:
Craig, Thanks for the explanation. > Historically, "backing bean" is a design idiom, not a required feature of > the specification. OK, but the term "backing bean" is used in a few places of the spec, and it would be nice if the spec defined it on the first encounter (or referred the reader to a glossary). :-) There are other terms, such as a component's "local value" that are used in the spec, without first being defined. Sometimes later, probably by reading the JavaDocs, the reader learns that the local value of a component is the value that is stored in a UIComponent instance's value property (am I right?) but, again, it would be better to have it defined on the first encounter. > Don't tie your design down to someone's definition of an idiom ... look for > the patterns that make the most sense for your application architecture. Actually I have a hard time coming up with a low-level architecture based on JSF. I can see many fellows just make every managed bean session-scoped but that's not a solution, is it? I have to admit that I am a newbie in this area but I thought understanding JSF should be easier than what I am going through. Nevertheless, a JSF blueprint project would be great.
The most common patterns you'll see are a bean per view (as I described above), or a bean per conversation. The thinking behind bean-per-view is that this bean is part of the view state -- it has the handlers that react to view tier events, and should delegate the real work to business logic objects. If you're coming from a ASP.Net background, this is similar to what you'd put in a "code behind file". If you're more familiar with a Java web framework like Struts or WebWork, this is more like an action. Typically, this sort of a backing bean would live in request scope (although it might delegate some data storage to session scope). Bean-per-conversation is more likely to make sense when it takes several interactions with this user (think of a wizard dialog) and you want to keep all of the data in the same place. This sort of bean would usually live in session scope, but (as always) the interesting challenge is knowing when to get rid of it. For fully worked out application architectures built on top of JSF (as opposed to frameworks that let you use JSF components within their own architectures), look at things like Shale[1] and Seam[2] which add lots of stuff useful to the application developer, while still working with pretty much any JSF UI components. Craig Best regards,
Behi
[1] http://shale.apache.org/ [2] http://jboss.com/products/seam/ --
"Science is a differential equation. Religion is a boundary condition" - Alan Turing Behrang Saeedzadeh http://www.jroller.com/page/behrangsa http://my.opera.com/behrangsa
