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
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.


Mime
View raw message