[
https://issues.apache.org/jira/browse/TRB-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl resolved TRB-74.
-------------------------------
Resolution: Fixed
Fixed in SVN for fulcrum-intake
> IntegerValidator does not default to "Entry was not a valid number" if the
> entry does not contain a valid number.
> -----------------------------------------------------------------------------------------------------------------
>
> Key: TRB-74
> URL: https://issues.apache.org/jira/browse/TRB-74
> Project: Turbine
> Issue Type: Bug
> Components: Fulcrum
> Affects Versions: Core 2.3.3
> Environment: Linux OS running turbine 2.3.3 & tomcat
> Reporter: Susi Berrington
> Assignee: Thomas Vandahl
> Priority: Minor
>
> We are using intake for our validation where possible and recently noticed
> that if the intake.xml file specifies a field with type="int" and doesn't
> specify an "invalidNumber" rule, i.e.:
> <group name="Config" key="ConfigKey" mapToObject="data.details.ConfigDetails">
> <field name="Field" key="field" type="int" mapToProperty="Field">
> <rule name="minValue" value="0">Please enter a value between
> 0 and 100</rule>
> <rule name="maxValue" value="100">Please enter a value
> between 0 and 100</rule>
> </field>
> </group>
> then there is no error message displayed when you call
> $intake.Config.Default.Field.Message. This is because this error message is
> only set in the org.apache.turbine.services.intake.validator.IntegerValidator
> constructor that takes a Map and the
> org.apache.turbine.services.intake.model.Field class which is creating the
> IntegerValidator calls the default constructor.
> I notice that in 2.4 M1 javadoc this whole section of code is deprecated in
> favour of package org.apache.fulcrum.intake.validator.IntegerValidator, etc.
> but looking at that source code the defect is still in there too.
> I've written this as a minor defect as the work around is to add the
> "invalidNumber" to the field's rules but this isn't a preferred long term
> solution.
> I think the best solution would be to initialize invalidNumberMessage to
> "Entry was not a valid number" in NumberValidator as a safety net. Then if
> any overriding class doesn't create their own default error message at least
> there would be a generic one set. And then in IntegerValidator,
> LongValidator, etc. either get both constructors to set a default message for
> invalidNumberMessage or try removing the default constructor and see if all
> the places which call the default constructor could call the other
> constructor?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
