On 11/18/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
The latter two methods will work *if* the bean already exists, *or* if you've defined "user" as a managed bean as well. In that case, it will do the normal "create this bean for you if it does not exist" trick, as well as looking it up for you.
Using the Map is better if you do *not* want to trigger a managed bean creation. But all of these methods are feasible.
That would be technically feasible, but it would break the contract for the default VariableResolver defined in the spec ... that doesn't seem like something you would want to have happen.
Actually, the Map in question is *required* by the spec to act the way it does. In fact, it's not a "real" Map at all (in the sense of something like HashMap or TreeMap) ... it is an abstraction that, underneath the covers, calls session.getAttribute(), session.setAttribute(), and so on. The reason a Map representation was chosen was to hide the fact that the underlying session object is an HttpSession if you're running in a standard webapp, or a PortletSession when you're running in a portlet.
Craig
Why is pulling the bean from the session map better than asking the
application for it using
facesContext.getApplication().getVariableResolver().resolveVariable("neededBean")
or facesContext.getApplication ().createValueBinding("#{neededBean}").getValue(facesContext),
which is what Don suggested?
The latter two methods will work *if* the bean already exists, *or* if you've defined "user" as a managed bean as well. In that case, it will do the normal "create this bean for you if it does not exist" trick, as well as looking it up for you.
Using the Map is better if you do *not* want to trigger a managed bean creation. But all of these methods are feasible.
Wouldn't it be possible that a custom variable resolver may not store
the bean in the session map under that name?
That would be technically feasible, but it would break the contract for the default VariableResolver defined in the spec ... that doesn't seem like something you would want to have happen.
Or perhaps there's some
other reason why this might not work in some alternate JSF
implementation. It just seems like you're working too close to the
internals by reading it out of the map yourself.
Actually, the Map in question is *required* by the spec to act the way it does. In fact, it's not a "real" Map at all (in the sense of something like HashMap or TreeMap) ... it is an abstraction that, underneath the covers, calls session.getAttribute(), session.setAttribute(), and so on. The reason a Map representation was chosen was to hide the fact that the underlying session object is an HttpSession if you're running in a standard webapp, or a PortletSession when you're running in a portlet.
Craig
