On Tue, Aug 7, 2012 at 6:20 PM, Edward Burns <edward.burns_at_oracle.com>wrote:
> >>>>> On Mon, 6 Aug 2012 06:01:12 -0700, Kito Mann <kito.mann_at_virtua.com>
> said:
>
> EB> First, let's set the terms straight. The "submittedValue" property is
> EB> *not* saved into the state. The local value property *is* saved into
> EB> the state, but we have elaborate logic to cover when the value should
> be
> EB> cleared if the component instance has a ValueExpression for its value.
>
> EB> Perhaps we should not include the value in the state if the component
> EB> has a ValueExpression for the value. Otherwise, it *must* be stored in
> EB> the state, because it is not stored anywhere else. Note that in the
> EB> case of a validation error, the invalid value will be conveyed in the
> EB> rendering of the component, so it doesn't need to be in the state.
>
> KM> That sounds like the simplest solution, and I think it would make
> things
> KM> much easier for developers to understand. However, if you reload the
> page,
> KM> you'll lose the current value, which I'm guessing will break some
> existing
> KM> applications. This could, of course, be something that is controlled
> via a
> KM> context parameter. I'm not sure what other side-effects we would find,
> but
> KM> I think this option is worth considering.
>
> On closer inspection, I don't think we can make that change, it's too
> fundamental. I tried it in a local workarea and a simple testcase we've
> had for nearly nine years failed immediately.
>
Oh well... I think the question is whether we should deal with this only in
the Ajax case, or if it's a potential problem in other cases that we
requires we handled at this level. I'm not sure.
>
> EB> I think Andy's tr:resetActionListener is the ticket. Should we move
> EB> forward with that?
>
> KM> I don't think that's adequate. The case I see often is manipulating a
> KM> backing bean value in a value-change listener and then rendering the
> KM> affected component. An actionListener won't help in that scenario.
> Unless
> KM> we fix the problem by removing the value from the state, we'll need to
> KM> integrate this with Ajax support in general. The solution I came up
> with
> KM> was to combine the PrimeFaces <p:ajax> tag with the PrimeFaces
> Extensions
> KM> <pe:resetInput> tag, so that any EditableValueHolder that's listed in
> the
> KM> render list for <p:ajax> will automatically have its value reset.
>
> Can you explain that a little more explicitly?
>
I'll get back to you when I have more time.
> Thanks,
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/
>