On Wed, Aug 8, 2012 at 5:59 AM, Çağatay Çivici <cagatay.civici_at_gmail.com>wrote:
>
> On 08.Ağu.2012, at 01:20, Edward Burns wrote:
>
> > 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.
> I was expecting failures due to this change as I've mentioned in my
> previous responses.
>
> Have we discussed how UIData stands in this? Assume you have a datatable
> with input fields inside it, in this case value must be saved in state for
> sure as it is same the component processed for each item.
>
> I'm +1 for an external solution like f:resetInput rather than changing a
> fundamental part in UIInput.
>
> I'll probably start working on p:resetInput soon so I can take
> responsibility to create a proposal with sample implementation in
> PrimeFaces for JSF 2.0 and 2.1 users.
>
As I mentioned earlier, I don't think <f:resetInput> is the best solution
by itself, because the developer has to explicitly add that component
everywhere they use <f:ajax>, which is a pain. In most cases when <f:ajax>
is used with an input control, other input controls (or panels, tabs, etc.)
are being updated, so if that's the case, why make them add an extra
component? I'm in favor of the combined approach that I've taken that
integrates this behavior into <f:ajax>. I'd be happy to share the work I've
done as a discussion point -- it just integrates <p:ajax> and
<pe:resetInput>. The real question will be whether the approach taken by
<pe:resetInput> is the best approach, or if something like the OmniFaces
solution is better. (I prefer <pe:resetInput> personally).
>
> Regards,
>
> Cagatay Civici
> PrimeFaces Lead
> JSF EG Member
> Prime Teknoloji
> www.prime.com.tr
>
>