I had the same problem as you. My backing bean would often need to hit my business tier and subsequently my database tier in order to retrieve valid values for drop down lists. Obviously this starts to become expensive if jsf is hitting the managed bean getter multiple times. What i found to work (maybe someone knows a simpler way) was using aspectj and writing an aspect which cached the value returned from a backing bean getter method for the duration of a single request. This way if the managed bean's getter was called multiple times it would only run through the entire method once. Once the request has finished the cache is cleared so that on next request you be sure to get the latest values. I also wrote advice for setter methods of the managebean to be sure to update the cached value if it was present.
Good luck On 6/14/05, Kris Verhoye <[EMAIL PROTECTED]> wrote: > Hi again! > > I've been reading through the lifecycle theory again and am confused about > the way getters and setters are handled: > > How comes that a backing bean getter/setter may be called more than once > during the lifecycle, and how does one initialize a list of selectItems > stored in a session scoped bean that should be refreshed every request? > > If I perform the construction of the list in a getter, it would be executed > more than once. I can't do it in the constructor however as the bean is not > constructed every request... > > Cheers, > Kris > > > >
