restoring the value of h:outputText after validation failure

[De...@ak.blm.gov]

I have an action that constructs a graph of objects and returns an outcome 
that forwards the request to a new view.  In this view, there is an 
h:outputText tag that displays a string value pulled from the graph.  When 
a user submits a request that causes a validation failure, MyFaces then 
looks back to the graph/model for the value.  Because the model (and 
consequently the string value) is in request scope, it is of course gone 
and an empty string is rendered.  This problem disappears if I change 
h:outputText to h:inputText - giving me the behavior (but not the UI 
control) I want.  Ideas?

Dennis Byrne

Re: restoring the value of h:outputText after validation failure

[Mike Kienenberger <mk...@gmail.com>]

Yeah, I think you're better off just preserving the entire OrderBacker.
It's not really request-scope, but page-scope.

On 9/7/05, Dennis_Byrne@ak.blm.gov <De...@ak.blm.gov> wrote:
>  
> Mike Kienenberger <mk...@gmail.com> wrote on 09/07/2005 09:07:01 AM:
>  
>  > Is there a reason why you dont preserve your OrderBacker backing bean
>  > with t:saveState? 
>  
> I just hadn't had the need until now.  My usual is to contruct a graph of
> objects in an action and let JSF's Apply Request Values handle the
> *RE*construction of this for each request cycle.
>  
> One solution that I am not too thrilled about at this point is to change the
> value binding to something that like #{OrderBacker.zipCodeHack} .  As you
> know, the JSF infrastructure would create the base, allowing state to be
> preserved using t:saveState w/out running into a null base exception. 
> Although this uses t:saveState w/ more precision, it complicates the backing
> bean.  For example, what if there needs to be 10 values preserved?

Re: restoring the value of h:outputText after validation failure

[De...@ak.blm.gov]

Mike Kienenberger <mk...@gmail.com> wrote on 09/07/2005 09:07:01 AM:

> Is there a reason why you dont preserve your OrderBacker backing bean
> with t:saveState?

I just hadn't had the need until now.  My usual is to contruct a graph of 
objects in an action and let JSF's Apply Request Values handle the 
*RE*construction of this for each request cycle.

One solution that I am not too thrilled about at this point is to change 
the value binding to something that like #{OrderBacker.zipCodeHack} .  As 
you know, the JSF infrastructure would create the base, allowing state to 
be preserved using t:saveState w/out running into a null base exception. 
Although this uses t:saveState w/ more precision, it complicates the 
backing bean.  For example, what if there needs to be 10 values preserved?

Re: restoring the value of h:outputText after validation failure

[Mike Kienenberger <mk...@gmail.com>]

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, Dennis_Byrne@ak.blm.gov <De...@ak.blm.gov> wrote:
>  
> Thanks for reply, comments inline. 
>  
> Dennis Byrne
>  
>  
> Mike Kienenberger <mk...@gmail.com> 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.

Re: restoring the value of h:outputText after validation failure

[De...@ak.blm.gov]

Thanks for reply, comments inline.

Dennis Byrne


Mike Kienenberger <mk...@gmail.com> 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.

Re: restoring the value of h:outputText after validation failure

[Mike Kienenberger <mk...@gmail.com>]

Dennis,

I'm not quite sure I'm following what you're doing.

Here's what I think you're saying:

1) "graph of objects" = "graph/model" = request-scoped data
2) h:outputText reads from the request-scoped data

Maybe you need to preserve h:outputText's value binding with t:saveState?

On 9/6/05, Dennis_Byrne@ak.blm.gov <De...@ak.blm.gov> wrote:
>  
> I have an action that constructs a graph of objects and returns an outcome
> that forwards the request to a new view.  In this view, there is an
> h:outputText tag that displays a string value pulled from the graph.  When a
> user submits a request that causes a validation failure, MyFaces then looks
> back to the graph/model for the value.  Because the model (and consequently
> the string value) is in request scope, it is of course gone and an empty
> string is rendered.  This problem disappears if I change h:outputText to
> h:inputText - giving me the behavior (but not the UI control) I want. 
> Ideas? 
>  
> Dennis Byrne
>