turbine-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Susi Berrington (JIRA)" <j...@apache.org>
Subject [jira] Created: (TRB-74) IntegerValidator does not default to "Entry was not a valid number" if the entry does not contain a valid number.
Date Mon, 31 Aug 2009 21:47:32 GMT
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: Core
    Affects Versions: Core 2.3.3
         Environment: Linux OS running turbine 2.3.3 & tomcat 
            Reporter: Susi Berrington
            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
                 <rule name="maxValue" value="100">Please enter a value between 0 and

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.

View raw message