[
https://issues.apache.org/jira/browse/TOMAHAWK-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605182#action_12605182
]
Leonardo Uribe commented on TOMAHAWK-750:
-----------------------------------------
There is a different problem with validateCompareTo
Checking this problem, the solution applied by TOMAHAWK-1048 and the actual
code I have noted that validateCompareTo try to compare values no matter if the
values are convertible or not. In other words, if we have this code:
<t:inputDate id="startDateInput" value="#{viewController.start}"
type="both" popupCalendar="true">
</t:inputDate>
<t:inputDate id="endDateInput" value="#{viewController.end}"
type="both" popupCalendar="true">
<s:validateCompareTo operator="gt" for="startDateInput"
message="#{appBundle.invalidDate}" />
</t:inputDate>
And startDateInput has a wrong value (throws a ConverterException when is
converter), for example when you add letters on the fields, validateCompareTo
try to convert the value and ignore the exception, and which is worst, use
always the submitted value (the submitted value could be anything). How we can
compare that anything is lower than or greater than some valid value.
The history is different if the non convertible value is on endDateInput. The
validation stops before validateCompareTo code is executed (see
UIInput.validate code).
The correct behavior is that the values inside components must be convertible
before compare it. If one value is not convertible, validation should not
continue, but do not throw any exception, because on the first component has
isValid() = false and no further advance can be done. We can throw an
ValidatorException here, but it is useless, because we are reporting one error
twice to the user.
This argumentation implies that TOMAHAWK-1048 ValidatorException should display
submitted values changes should be rollback, because it does not have sense to
show submitted values if we ensure that the validator operates on convertible
values only.
> Raized ClassCastException when Comparing 2 InputDate with validateCompareTo
> ---------------------------------------------------------------------------
>
> Key: TOMAHAWK-750
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-750
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: Validators
> Affects Versions: 1.1.5-SNAPSHOT
> Environment: windows XP
> Reporter: Nuno Marques
>
> I have two inputDate components with their own validators and a compareTo
> validator:
> <t:inputDate id="startDateInput" value="#{viewController.start}"
> type="both" popupCalendar="true">
> <f:validator validatorId="validateDate" />
> </t:inputDate>
> <t:inputDate id="endDateInput" value="#{viewController.end}"
> type="both" popupCalendar="true">
> <f:validator validatorId="validateDate" />
> <s:validateCompareTo operator="gt" for="startDateInput"
> message="#{appBundle.invalidDate}" />
> </t:inputDate>
> When, for instance, the validator of the "startDateInput" throws a
> ValidatorException and sets the valid property as false, validateCompareTo
> raizes a ClastCastException saying that class UserData is not Comparable.
> I looking deeper into the source code and found that:
> 1 - The class UserData is an internal representation of the submitted value
> by the InputDate component (though the class is public).
> 2 - The validateCompareTo gets this internal representation when he gets the
> submitted value because the value is not valid.
> 3 - When one or both values of the compared components are not Comparable, a
> ClassCastException is raized.
> I am submitting this as a bug because:
> 1 - I think that internal representations of objects shouldn't be accessed
> outside the scope of the objects.
> 2 - The JSF spec 1.1 says that (pag.3-18; 3.2.5.1) :
> submittedValue
> RW Object
> The submitted, unconverted, value of this component. This property should
> only be set by the decode() method of this component, or its corresponding
> Renderer, or by the validate method of this component. This property should
> only be read by the validate() method of this component.
> 3 - When I saw the Javadoc of validateCompareTo, I found the following
> statement:
> If no comparator is specified, the component values must implement Comparable
> and are compared using compareTo(). If either value or foreign value does not
> implement Comparable and no Comparator is specified, validation always
> succeeds.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
