Re: Backing Bean in Request Scope Persists Beyond Request
I think the problem is using outputLink instead of commandLink components.outputLink simply generates an a tag.. and it is intended for building links that go outside of the JSF scope (a link to another website or to a file on disk, for example). Are you using outputLink for some particular reason? In JSF, you should use commandLink (or commandButton) to trigger a JSF request/response. Cosma2006/7/5, Dhananjay Prasanna [EMAIL PROTECTED]: -Original Message- From: Mike Duffy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 5 July 2006 2:33 PM To: MyFaces Discussion Subject: Re: Backing Bean in Request Scope Persists Beyond Request In a Google sarch I saw the following in a post from Craig: You can accomplish that with standard managed beans my setting the managed-bean-scope on the businessDelegate bean to be none. This is like the create-every-time mode of Spring ... you always get a new instance each time the _expression_ is evaluated, and it is never placed into any scope. Craig http://www.nabble.com/RE:-managed-properties-t1846249.html This works; however, the only problem is that it seems like a new backing bean object is created every time each component on the page is referenced (over twenty times for the page I am working with). Is there a better solution? This is from the answer craig gave to a question I asked. It was regarding nesting managed beans inside other managed beans, certainly not for backing beans themselves (as you correctly point out it will generate a new bean on every call). As far as I am aware a link is not allowed to make a POST. Therefore params should not be set this way (unless they are built into the URL which JSF does not cleanly allow for). Correct me if Im wrong, people. What I think you're attempting to do is to set a value in a backing bean based on which of your 5 links is clicked. If this is so, you should use the JSF actionListener binding. If this answer is insufficient--can you post some of your jsp and faces-config source? Dhanji. Mike This correspondence is for the named persons only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis transmission. If you receive this correspondence in error please delete it from your system immediately and notify the sender. You must not disclose, copy or relay on any part of this correspondence, if you are not the intended recipient. Any opinions expressed in this message are those of the individual sender except where the sender expressly, and with the authority, states them to be the opinions of the Department of Emergency Services, Queensland.
Re: Backing Bean in Request Scope Persists Beyond Request
In a Google sarch I saw the following in a post from Craig: You can accomplish that with standard managed beans my setting the managed-bean-scope on the businessDelegate bean to be none. This is like the create-every-time mode of Spring ... you always get a new instance each time the expression is evaluated, and it is never placed into any scope. Craig http://www.nabble.com/RE:-managed-properties-t1846249.html This works; however, the only problem is that it seems like a new backing bean object is created every time each component on the page is referenced (over twenty times for the page I am working with). Is there a better solution? Mike --- Mike Duffy [EMAIL PROTECTED] wrote: I have a JSP (some.jsp) which is mapped to a backing bean (SomeBean.java). The scope is set to request. In some.jsp there are five h:outputLink tags each with its own f:param tags. The value for each of the h:outputLink tags is some.jsp. When a link is clicked I want to set the param values into the backing bean and redisplay the page showing the new values (I am doing this in the constructor of SomeBean.java). This only works on the first time I click a link, even though the scope of SomeBean.java is definitely set to request. The very weird thing about this is that when I trace the code, the new param values are definitely being set in a new SomeBean.java, and then (through some sort of black magic) the old values from the previous request are mapped back into the new bean. I thought that if I set the scope of the backing bean to request, the backing bean would not persist beyond requests. Can anyone explain what is going on and possibly offer a solution? Thx. Mike __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE: Backing Bean in Request Scope Persists Beyond Request
-Original Message- From: Mike Duffy [mailto:[EMAIL PROTECTED] Sent: Wednesday, 5 July 2006 2:33 PM To: MyFaces Discussion Subject: Re: Backing Bean in Request Scope Persists Beyond Request In a Google sarch I saw the following in a post from Craig: You can accomplish that with standard managed beans my setting the managed-bean-scope on the businessDelegate bean to be none. This is like the create-every-time mode of Spring ... you always get a new instance each time the _expression_ is evaluated, and it is never placed into any scope. Craig http://www.nabble.com/RE:-managed-properties-t1846249.html This works; however, the only problem is that it seems like a new backing bean object is created every time each component on the page is referenced (over twenty times for the page I am working with). Is there a better solution? This is from the answer craig gave to a question I asked. It was regarding nesting managed beans inside other managed beans, certainly not for backing beans themselves (as you correctly point out it will generate a new bean on every call). As far as I am aware a link is not allowed to make a POST. Therefore params should not be set this way (unless they are built into the URL which JSF does not cleanly allow for). Correct me if Im wrong, people. What I think youre attempting to do is to set a value in a backing bean based on which of your 5 links is clicked. If this is so, you should use the JSF actionListener binding. If this answer is insufficient--can you post some of your jsp and faces-config source? Dhanji. Mike This correspondence is for the named persons only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis transmission. If you receive this correspondence in error please delete it from your system immediately and notify the sender. You must not disclose, copy or relay on any part of this correspondence, if you are not the intended recipient. Any opinions expressed in this message are those of the individual sender except where the sender expressly, and with the authority, states them to be the opinions of the Department of Emergency Services, Queensland.
