Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

JSF Variable State: Odd Behavior

 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Varun Khanna
Ranch Hand
Posts: 1400
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 Khanna
Ranch Hand
Posts: 1400
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1400
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 92
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Varun Khanna
Ranch Hand
Posts: 1400
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic