jsr344-experts@javaserverfaces-spec-public.java.net

[jsr344-experts] Re: [1129-ClearInputValues] Resume Discussion

From: Kito Mann <kito.mann_at_virtua.com>
Date: Mon, 6 Aug 2012 06:01:12 -0700

On Fri, Aug 3, 2012 at 12:45 PM, Edward Burns <edward.burns_at_oracle.com>wrote:

>
> >>>>> On Wed, 15 Jun 2011 13:59:02 -0400, Andy Schwartz <
> andy.schwartz_at_oracle.com> said:
>
> AS> Aside from the "reset" use case, another reason that this question
> might
> AS> be worth examining more closely: if we don't need to state save the
> AS> value attribute, it would be nice to remove this overhead from/reduce
> AS> the size of our partial state saving state.
>
> First, let's set the terms straight. The "submittedValue" property is
> *not* saved into the state. The local value property *is* saved into
> the state, but we have elaborate logic to cover when the value should be
> cleared if the component instance has a ValueExpression for its value.
>
> Perhaps we should not include the value in the state if the component
> has a ValueExpression for the value. Otherwise, it *must* be stored in
> the state, because it is not stored anywhere else. Note that in the
> case of a validation error, the invalid value will be conveyed in the
> rendering of the component, so it doesn't need to be in the state.
>

That sounds like the simplest solution, and I think it would make things
much easier for developers to understand. However, if you reload the page,
you'll lose the current value, which I'm guessing will break some existing
applications. This could, of course, be something that is controlled via a
context parameter. I'm not sure what other side-effects we would find, but
I think this option is worth considering.

>
> I think Andy's tr:resetActionListener is the ticket. Should we move
> forward with that?
>

I don't think that's adequate. The case I see often is manipulating a
backing bean value in a value-change listener and then rendering the
affected component. An actionListener won't help in that scenario. Unless
we fix the problem by removing the value from the state, we'll need to
integrate this with Ajax support in general. The solution I came up with
was to combine the PrimeFaces <p:ajax> tag with the PrimeFaces Extensions
<pe:resetInput> tag, so that any EditableValueHolder that's listed in the
render list for <p:ajax> will automatically have its value reset.

>
> Thanks,
>
> Ed
>
> [1]
> https://maven.java.net/service/local/repositories/releases/archive/javax/faces/javax.faces-api/2.0/javax.faces-api-2.0-javadoc.jar/!/javadocs/javax/faces/validator/Validator.html#validate(javax.faces.context.FacesContext,%20javax.faces.component.UIComponent,%20java.lang.Object)
>
> [2]
> http://myfaces.apache.org/trinidad/trinidad-api/tagdoc/tr_resetActionListener.html
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/
>