Is there a reason why you dont preserve your OrderBacker backing bean
with t:saveState?
It would seem as if you'd need it until you successfully validated the
order or left the order page.
To answer your question,
Yes, during renderResponse, the outputText is always going to go to
your backing bean since that's what its value is bound to.
For UIInput components, it's different since the value binding is a
three-tier model: the submitted value, the local value stored in
UIInput, and the model binding if specified. You'd have to verify it,
but I think that during rendering, UIInput read first from submitted
value, then from the local value, and then from the model, depending
on the state of the internal UIInput data model.
The task of UIOutput is to bring data from your model to the page, but
the task of UIInput is to bring data from your page to the model, thus
they behave differently on re-rendering the page.
On 9/7/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Thanks for reply, comments inline.
>
> Dennis Byrne
>
>
> Mike Kienenberger <[EMAIL PROTECTED]> wrote on 09/07/2005 07:18:02 AM:
>
> > 1) "graph of objects" = "graph/model" = request-scoped data
>
> Yeah, something like
> #{OrderBacker.currentOrder.customer.address.zipCode}
>
> > 2) h:outputText reads from the request-scoped data
>
> Yes, OrderBacker is a request scoped bean
>
> > Maybe you need to preserve h:outputText's value binding with t:saveState?
>
> The farthest I got was <t:saveState
> value="#{OrderBacker.currentOrder.customer.address.zipCode}"
> /> ... which of course blows up because the base is null.
>
> I can confirm however that MyFaces is going to the model after validation
> fails. For example, if I change the value binding to #{OrderBacker.string},
> logging statements in OrderBacker.getString() show the following ...
>
> 1.) request sent
> 2.) getString is called
> 3.) response rendered, showing value from the model (zipCode)
> 4.) submit form, request sent
> 5.) validation failure
> 6.) getString is called again
> 7.) response rendered w/ blank value
>
> It's as if JSF "thinks" like this at the point in which validation has
> failed: OK validation has failed for this request, better render the last
> response w/ the values of this request. Oops, there is no request value for
> this h:outputText ... let's look back at the model.
