f:convertNumber triggers call to set method on tr:inputText, effectively overwriting the property in the wrong object

[Bastian.Krol]

Hello everybody.

Versions used: myfaces-core: 1.2.7 & trinidad: 1.2.11

I have the following code in my view:

  <tr:form>
    <tr:selectOneChoice id="containerObject"
      value="#{bean.containerObject}" label="Container-Objekt"
      autoSubmit="true">
      <f:selectItems value="#{bean.containerObjectList}" />
    </tr:selectOneChoice>

    <tr:inputText id="property" label="Property"
      partialTriggers="containerObject"
      value="#{bean.containerObject.property}" autoSubmit="true">
      <f:convertNumber pattern="#,##0.00" />
    </tr:inputText>
  </tr:form>

A rather simple setup: Using the tr:selectOneChoice, users can select
different
instances of class ContainerObject, which are stored in the backing bean as a
list of SelectItems (bean.containerObjectList. The tr:inputText refers to a
property of such a ContainerObject. The tr:inputText always shows the
property
value of the ContainerObject that is selected in the tr:selectOneChoice. Note
that the tr:inputText has a f:convertNumber child. ContainerObject.property
is
of type BigDecimal.

Without the converter, everything works fine. But when the tr:inputText has a
converter (no matter if it is a standard converter or a custom converter
defined
by the converter attribute) there is a problem in the update model phase if
the
user selects a different entry in the tr:selectOneChoice.

Example: We have two ContainerObjects A and B, with A.property = 1.00 and
B.property = 2.00. A is selected in the tr:selectOneChoice. Now select B.
What
happens in update model phase is this:

2009-07-28 14:11:54,377 13850 DEBUG st.DebugPhaseListener -
DebugPhaseListener: Before - UPDATE_MODEL_VALUES(4)
2009-07-28 14:11:54,377 13850 DEBUG test.Bean - Bean#setContainerObject with
argument "Container-Object B [hash: 1099257, property: "2")"
2009-07-28 14:11:54,377 13850 DEBUG test.Bean - Bean#getContainerObject
2009-07-28 14:11:54,377 13850 DEBUG test.ContainerObject -
ContainerObject#setProperty on Container-Object B [hash: 1099257, property:
"2") with argument "1.00"
2009-07-28 14:11:54,377 13850 DEBUG st.DebugPhaseListener -
DebugPhaseListener: After - UPDATE_MODEL_VALUES(4)


Observed behaviour:

First, Bean#setContainerObject is called as expected. Now the backing bean
has B
as it's currently selected ContainerObject. After that
ContainerObject#setProperty is called with the value from the tr:inputText,
that
is, 1.00. Because the currently selected ContainerObject has already been set
to
B, B.property is set to 1.00.

==

Expected behaviour:

The tr:inputText was not touched by the user, so I think
ContainerObject#setProperty should not be called at all in this request.
B.property should not be overwritten with the value of A.property (or rather
with the value from the tr:inputText which happens to be A.property).

==

I believe the observed behaviour is triggered by the converter, maybe because
he
"changes" the value by converting it in the process validations phase - even
if
the user did not change it. This does not happen if the tr:inputText has no
converter.

Funny enough, this does not happen if you edit the input field before the
using
the tr:selectOneChoice. Perhaps because the value gets converted in the
request
that directly follows the editing (tr:inputText has autoSubmit="true")

While debugging I noticed the following:

org.apache.myfaces.trinidad.componen.UIXEditableValue#updateModel contains
this
code:

    if (!isValid() || !isLocalValueSet())
      return;

If there is no converter, isLocalValueSet returns false, so updateModel is
cancelled. If there is a converter, isLocalValueSet returns true even if the
user did not edit the tr:inputText. This in turn leads to calling
ContainerObject#setProperty.

This could be related to https://issues.apache.org/jira/browse/TRINIDAD-1489

Regards

  Bastian Krol

--
Die Continentale
Abteilung ik1-k, Bastian Krol
Ruhrallee 92-94, 44139 Dortmund
Telefon: [phone]
bastian.krol@...

[Bastian Krol]

Bastian.Krol wrote:

This could be related to https://issues.apache.org/jira/browse/TRINIDAD-1489

Obviously this is indeed the case. It all worked well after patching UIXEditableVale with the changes from revision 788207 (fix for https://issues.apache.org/jira/browse/TRINIDAD-1489) and revision 789984 (improvement for the former fix, https://issues.apache.org/jira/browse/TRINIDAD-1522). So this will be fixed in 1.2.12.

Regards

  Bastian Krol