On 6/14/05, albartell <[EMAIL PROTECTED]> wrote: > > Why are you hung up on using only one backing bean? Use as many as > you need -- and needing different lifetimes for data is *definitely* a > good reason to use more than one bean as necessary. > > I agree this is the direction I need to head. I was just concerned about > the number of objects and how to organize (say name) them. I have used IBM's > Websphere IDE and they create a backing bean per page which seems like the > appropriate amount to create. >
Sun Java Studio Creator (disclaimer: that's the product I am architect for) goes a bit further -- we also create a session-scoped managed bean and an application-scoped managed bean for you. Then we make it easy to add property getters that can do caching-like things, and then bind to them. A request scoped backing bean per page is fine for stuff that only needs to be visible through the current request, for the current page. If you need stuff longer, keep it in a bean that is in a longer scope. > > >... It is not JSF's responsibility to ensure that you make sure > getStates() is as efficient as possible. > > Given your example I would fully expect the getter to be called twice if > there are two components on the screen accessing the same backing bean > property. But that isn't the scenario I have. I instead have a single field > (i.e. title - Mr., Ms., Mrs. etc) that is only specified once on the page, > but the getter will still be called more than once in some instances. > That all depends on how many expression evaluations occur, because JSF never calls these methods by itself ... it only resolves expressions for you. > > If you like init() and destroy() on backing beans, you'll definitely > like Shale :-) > > Looks like I need to break down and do a little reading :-) > Yep :-) > Thanks for your response, > Aaron Bartell > Craig > > >
