Just to jump in with another option: this is one of the ways PAC is a
great alternative to MVC. In PAC, you basically have hierarchies and
each component snaps into an event stream from a coordinating
component. From there, it's just simple Observer. So for instance, in
the case of a dropdown that contains, for example, a list of people who
are currently online, you would make a PAC component that holds a list
of those people, but rather than handing out references to the list, it
would put out a simple interface, and it would allow listeners to
attach. This case is a perfect example for PAC because in fact, the
downstream component contains basically the same data, but instead of
strings, it is holding a collection of SelectItems in its abstraction.
When a new person comes online, or one goes off, the downstream
component is notified and updates its own state.
-Rob
On Feb 14, 2005, at 7:45 AM, Rick Reumann wrote:
Craig McClanahan wrote the following on 2/11/2005 11:45 AM:
My recommendation is to use request scope for backing beans in a JSF
application, storing stuff in session and appiication scope only where
it's needed:
* Session scope for per-user state that changes, or for
passing data across requests (as an alternative to having
to save and restore the data yourself).
* Application scope for caching things like arrays of SelectItems
that back a dropdown list, but are shared across all users.
I haven't had much luck with the later situation for application
scope. I do use Application scope for such things as having a
Constants Map in scope that the front end might need access to, but
for drop down lists unless it's 'definitely' not going to change I
don't like application scope since any changes to the backend database
aren't going to be picked up until the server restarts. I tend to opt
now for making calls to the persistence layer to re-get my Lists that
I need again. This lets the persistence layer worry about caching if
it needs to. Sure a method call will be more expensive than using a
list or array already in applicaiton scope, but to me it's a fair
trade off. I've been burned too many times thinking "this list of
options will never change" and sure enough someone makes a change to
the backend and it's not reflected by your app and then you get the
annoying phone calls:)
--
Rick
