Dennis Byrne wrote:
During the render response phase of the first request, #{backing.project.description} will be rendered as the value of [EMAIL PROTECTED] if #{backing.renderMode eq 'edit'} .
OK, this makes sense; I have an action method to initiate editting which
sets renderMode to 'edit' then forwards to the view, satisfying this
condition.
However the value for [EMAIL PROTECTED] (coming back from the browser) will not be assigned back to #{backing.project.description} if #{backing.renderMode eq 'edit'} is false during the second request. This is probably the case if #{backing} is in request scope and the renderMode property is not initialized to 'edit' .
>
In other words, it sounds as though you want backing.renderMode to be a
"conversation piece" . Apparently the hidden input field is accomplishing this
for you. You may want to look into t:saveState as an alternative.
I'm not sure what you mean by 'conversation peice' but I think I
understand what you're saying. The backing bean is in request scope and
renderMode defaults to 'view' if there isn't a request parameter to set
it to something else. So when the form is submitted and the component
tree (re)built, the [EMAIL PROTECTED] will be excluded due to its
rendered property evaluating to false. And that's the reason the model
update doesn't happen?
Also note that the call to getDescription() is going to happen whether
#{backing.renderMode eq 'edit'} or #{not empty backing.project and
backing.renderMode eq 'view'}" evaluate to true during the render response
phase of any request. This is because #{backing.project.description} is set for
@value for both the inputText and the outputText. You may have to read this more
than once ;)
Er, a couple of times :-) Yes, it makes sense; either getDescription()
will be called to render the outputText (view) or it will be called to
render the inputText (edit). And because (without the hidden field)
renderMode is effectively not preserved through the whole 'edit
operation' (initial render and subsequent submit), the inputText gets
replaced with an outputText at the wrong stage.
Gak, I'm not sure I made much sense myself there :-) But I do think I
understand what's going on now, thanks. I'll look into saveState and see
if it provides a nicer solution than the hidden input -- or if I can
avoid both by including the request parameter in the view ID, which is
where I intend to end up to support bookmarking.
L.
-----Original Message-----
From: Laurie Harper [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 5, 2006 04:01 PM
To: users@myfaces.apache.org
Subject: model update failing, I can't see why
I have this really weird problem I can't explain. I'm hoping someone can
give me some insight. The problem is that my backing bean isn't being
updated properly during the update model phase, *unless* I include a
hidden input. With the source listed below it works fine, but if I
remove the h:inputHidden I get a call to getDescription() instead of
setDescription().
The action for the h:commandButton fires, but because the model hasn't
been updated it has no effect. Here's the code:
<h:commandButton value="#{msgs['label.Save']}"
action="#{backing.save}"/>
<h:inputText id="description"
value="#{backing.project.description}"
rendered="#{backing.renderMode eq 'edit'}"/>
<h:inputHidden id="mode" value="edit"
rendered="#{backing.renderMode eq 'edit'}"/>
<h:outputText
value="#{backing.project.description}"
rendered="#{not empty backing.project
and backing.renderMode eq 'view'}"/>
As I say, as long as I have that hidden input everything's fine. I have
an h:messages in my view and it's not showing any conversion or
validation errors, with or without the hidden input.
I don't understand :-( Any help would be appreciated!
L.
