aspose file tools*
The moose likes Struts and the fly likes JSF Variable State: Odd Behavior Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Frameworks » Struts
Bookmark "JSF Variable State: Odd Behavior" Watch "JSF Variable State: Odd Behavior" New topic
Author

JSF Variable State: Odd Behavior

Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15292
    
    6

Working on a form I ran into a strange thing that I can't find any documentation on. I have a form with some non-editable information that I need displayed and then below that there is some editable information.

If I use outputText for the non-editable data and submit the form, when/if validation fails and the form returns the outputText values are blank. So I switched to inputText components with disabled="true". And guess what, the same thing happens. So I used an inputText with readonly="true" and this worked the way I wanted it to.

Now, if I put the managed bean in the session it seems to work just fine anyway I want to do it. But putting it in the request makes this happen. Does anyone have an explination for this?


GenRocket - Experts at Building Test Data
Varun Khanna
Ranch Hand

Joined: May 30, 2002
Posts: 1400
Originally posted by Gregg Bolinger:
Working on a form I ran into a strange thing that I can't find any documentation on. I have a form with some non-editable information that I need displayed and then below that there is some editable information.

If I use outputText for the non-editable data and submit the form, when/if validation fails and the form returns the outputText values are blank. So I switched to inputText components with disabled="true". And guess what, the same thing happens. So I used an inputText with readonly="true" and this worked the way I wanted it to.

Now, if I put the managed bean in the session it seems to work just fine anyway I want to do it. But putting it in the request makes this happen. Does anyone have an explination for this?


That's perfectly fine. Now, here is what the JSF specification says:

"At the end of APPLY_REQUEST_PHASE, all EditableValueHolder components in the component
tree will have been updated with new submitted values included in this request (or
enough data to reproduce incorrect input will have been stored, if there were
conversion errors). In addition, conversion and validation will have been performed on EditableValueHolder components whose immediate property is set to true.
Conversions and validations that failed will have caused messages to be enqueued via calls to the addMessage() method of the FacesContext instance for the
current request, and the valid property on the corresponding component(s) will be set to false."


In simple terms,
output text is never submitted in the request, (makes sense as JSF expect you are never going to make any change in the non-editable field), same applies for the disabled fields.

But for input fields, since it implements "EditableValueHolder" it submits in request.
Now if you put your bean in session, it's worknig your way simply because your bean is in the session.

When your backing bean is in the request scope, if you submit a form
a new backing bean instance is created, now for outputText the new bean won't have any value (since request is not carrying one), but for input text it will have
.... and if you make your bean in session, the issue fixes since the bean and its attributes will last your entire session (since outputText is not submitted, JSF is not going to touch binded variables of backing bean and hence they will be preserved)
[ December 14, 2004: Message edited by: K Varun ]

- Varun
Varun Khanna
Ranch Hand

Joined: May 30, 2002
Posts: 1400
Just noticed, see this message posted today by a rancher. He is putting his backing bean in session just to re-display his "read-only" (i.e. containing outputTexts) page.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15292
    
    6

Thanks. That makes perfect sense! I can't put this form in the session so I'll just be putting the values in readonly text fields.

Thanks again.
Varun Khanna
Ranch Hand

Joined: May 30, 2002
Posts: 1400
Originally posted by Gregg Bolinger:
Thanks. That makes perfect sense! I can't put this form in the session so I'll just be putting the values in readonly text fields.

Thanks again.


Or you may create hidden variables and use them to persist the outputText values.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15292
    
    6

Originally posted by K Varun:


Or you may create hidden variables and use them to persist the outputText values.


I thought about that but it's kind of 6 one way half a dozen the other. It works fine the way it is.
Henrique Sousa
Ranch Hand

Joined: Apr 29, 2004
Posts: 92
Hi,
Just another thought on the subject: using inputText with disabled attribute won't work because of HTML, not JSF. outputText is not included in the request, I suppose this was settled previously. HTML input elements with the disabled attribute set will not be included in the request either. One way around that is with JavaScript dealing with the form submit which would enable all disabled inputText before the submit, and disable them again afterwards. I have used this very nicely with Struts.
Another simple (and quite readable) way is to set the readonly attribute. That way the fields won't be editable either, but will be included in the request. Adding onfocus="this.blur()" makes sure it will not receive focus.


Henrique Sousa<br />SCJP 1.4<br /> <br />All men die, not all men really live - Braveheart, 1995
Varun Khanna
Ranch Hand

Joined: May 30, 2002
Posts: 1400
One way around that is with JavaScript dealing with the form submit which would enable all disabled inputText before the submit, and disable them again afterwards.


Well it's not going to be so simple in JSF. Just enabling the input components before submitting the page, "probably" won't work as at the server side these components will still be disabled and hence JSF won't expect any value from you (even if you send it in request ).

Well in JSF if you are playing around with components using Java script, then ensure the component at server side is also changed accordingly.

But all I said above is for Server side state saving, not sure if on Client Side State Saving it will work. Though on gut feeling I would say it wont'.
Ck Lee
Greenhorn

Joined: Apr 05, 2010
Posts: 2
I have the same issue. I need to ensure that a report_id value is kept on the backing bean unless
it changed by a URL parameter to the JSF page. I tried using InputText with readOnly, but when I
perform an action, the value reverted back to the 1st set value. I tried using a normal InputText
(without the ReadOnly) and also set onfocus="this.blur()". This works for most cases except
if the user clicks on the browser refresh button. This causes the whole page to be resubmitted
and the cached value of the inputText parameter then reset the values in the JSF page.
BTW, my bean is in Request scope.

Is there any other way to keep the parameter on the JSF backing bean and keep it non-editable
without change it to Session scope ?

CK
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JSF Variable State: Odd Behavior
 
Similar Threads
datatable contents not updating
Getting null value in managed bean when readonly=true is given for h:inputText
JTree node as non editable
jsf ajax rerender inputText
Update OutputText using Java Script.