You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Scott Eade <se...@backstagetech.com.au> on 2003/09/12 07:26:43 UTC
Intake bug: setRequired(true) does not display messages
It seems that intake has a few bugs at present.
1. Colin is looking into the DateString problem.
2. I have committed Jürgen's patch to fix to the problem
whereby empty fields were not being accepted even when
required=false.
I'm now running into a further problem whereby required
messages are not being displayed when they should.
This is a particular case where required=false in intake.xml:
<field name="Amount" key="amt" type="BigDecimal">
<rule name="required" value="false">Please enter a value.</rule>
<rule name="minValue" value="0">Value must be >= 0.</rule>
<rule name="maxValue" value="1000000">Please enter a more sensible
value.</rule>
<rule name="invalidNumber" value="true">The value entered must be a
number.</rule>
</field>
but in my action I want to go:
group.get("Amount").setRequired(true);
if (!group.isAllValid())
{
return;
}
This worked previously and it still does when the now deprecated
<required-message> element is included in the field. The
recommended replacement of <required-message> is however the
required rule that I have above.
It seems that the current implementation of Field.setRequired()
acts only upon the old required-message message which in my case
is blank, thus I get an error that is not displayed!
So I could in theory do the following in my action:
((DefaultValidator)
group.get("Amount").getValidator()).setRequired(true);
But this doesn't actually work. If it did then I would patch
Field.setRequired() actually do this (I have the code, but since
it doesn't work anyway there is no point committing it).
I've spent as much time on this as I can afford to - the work
around is to switch back to <required-message> for optional
fields (which is what I would recommend since once fixed only
intake.xml need be updated) or to go:
group.get("Amount").setRequired(true,
((DefaultValidator)
group.get("Amount").getValidator()).getRequiredMessage());
which works, but is somewhat less than elegant :-)
One further alternative would be to go:
group.get("Amount").setRequired(true, "Enter a value!");
But I the <required-message> solution will be the easiest to tidy
up from once this is fixed.
Needless to say the Intake documentation is way out of date -
e.g. the "invalidNumber" rule is referred to as "notANumberMessage".
and there is still no complete rule reference available.
I'm not complaining - just pointing out a couple of shortcomings.
If I had time I would have a go at updating these documents, but
unfortunately I need to get back to some other pressing work.
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
Re: Intake bug: setRequired(true) does not display messages
Posted by Colin Chalmers <Co...@xs4all.nl>.
Hi Angelo,
Not sure if I undertsand this correctly. The problem is not the
inputting of dates in a specific format but if the date is valid how
that date is shown on the next page say, or if another input field was
incorrect; the (correct) date should be shown together with the
incorrect field and it's error message. The former works great which is
probably what you're using but the latter doesn't, instead just shows a
String dump of the Date Object.
The snip I showd merely returns the String representation of the Object
in question, in this case the correctly formatted Date.
Question is whether the IntakeService should take care of (number)
formatting or if a seperate tool should do this. We already have a
DateFormat Pull tool.
Colin
>I use StringDate fields with multiple format rules (to allow for different
>separators on input, everybody seems to like writing date values their own
>way :-), so I don't see how the field itself should adapt its value to one
>or the other of the different formats.
>
>Angelo Turetta
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Intake bug: setRequired(true) does not display messages
Posted by Colin Chalmers <Co...@xs4all.nl>.
Hi Angelo,
Not sure if I undertsand this correctly. The problem is not the
inputting of dates in a specific format but if the date is valid how
that date is shown on the next page say, or if another input field was
incorrect; the (correct) date should be shown together with the
incorrect field and it's error message. The former works great which is
probably what you're using but the latter doesn't, instead just shows a
String dump of the Date Object.
The snip I showd merely returns the String representation of the Object
in question, in this case the correctly formatted Date.
Question is whether the IntakeService should take care of (number)
formatting or if a seperate tool should do this. We already have a
DateFormat Pull tool.
Colin
>I use StringDate fields with multiple format rules (to allow for different
>separators on input, everybody seems to like writing date values their own
>way :-), so I don't see how the field itself should adapt its value to one
>or the other of the different formats.
>
>Angelo Turetta
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
>
>
>
Re: Intake bug: setRequired(true) does not display messages
Posted by Angelo Turetta <at...@commit.it>.
----- Original Message -----
From: "Colin Chalmers" <Co...@xs4all.nl>
Sent: Friday, September 19, 2003 12:18 AM
> If you look into the Field class there are several properties that seem
> to hold similiar information; testValue, validValue, emptyValue &
> stringValue. This doesn't help things! But the stringValue is set to the
> correct format!! and could/should? be returned from the getValue method
> which from what I see is used for displaying data on screen. The setting
> of properties on Object's using IntakeTool does not seem to utilise this
> method.
>
> <snip Field.java line 801>
> val = stringValue; //getTestValue();
> </snip>
>
I use StringDate fields with multiple format rules (to allow for different
separators on input, everybody seems to like writing date values their own
way :-), so I don't see how the field itself should adapt its value to one
or the other of the different formats.
Angelo Turetta
Re: Intake bug: setRequired(true) does not display messages
Posted by Angelo Turetta <at...@commit.it>.
----- Original Message -----
From: "Colin Chalmers" <Co...@xs4all.nl>
Sent: Friday, September 19, 2003 12:18 AM
> If you look into the Field class there are several properties that seem
> to hold similiar information; testValue, validValue, emptyValue &
> stringValue. This doesn't help things! But the stringValue is set to the
> correct format!! and could/should? be returned from the getValue method
> which from what I see is used for displaying data on screen. The setting
> of properties on Object's using IntakeTool does not seem to utilise this
> method.
>
> <snip Field.java line 801>
> val = stringValue; //getTestValue();
> </snip>
>
I use StringDate fields with multiple format rules (to allow for different
separators on input, everybody seems to like writing date values their own
way :-), so I don't see how the field itself should adapt its value to one
or the other of the different formats.
Angelo Turetta
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Intake bug: setRequired(true) does not display messages
Posted by Colin Chalmers <Co...@xs4all.nl>.
Hi Scott,
I've been looking into the DateString problem and know where the problem
lies, but unsure as to solution. I can offer you a workaround which
seems to work here but is NOT properly tested.
The problem lies in the fact that the Fields (ie DateStringField) return
an Object corresponding to their type in the getValue method. In our
case a Date Object is returned that has been initialised to that of the
input data. When the Date object is written to screen it shows the Date
correctly but NOT in the desired format. As you already know :-)
If you look into the Field class there are several properties that seem
to hold similiar information; testValue, validValue, emptyValue &
stringValue. This doesn't help things! But the stringValue is set to the
correct format!! and could/should? be returned from the getValue method
which from what I see is used for displaying data on screen. The setting
of properties on Object's using IntakeTool does not seem to utilise this
method.
<snip Field.java line 801>
val = stringValue; //getTestValue();
</snip>
Show's the data in the correct format.
However I am in two minds if the formatting of data belongs in the
IntakeService OR should be seperate in Localization/Internationalization
Tools?? Anyone got ideas on this??
I see that some of the Field classes are in need of refactoring, if
nothing else to simplify the use of some properties.
Colin
Scott Eade wrote:
> Colin Chalmers wrote:
>
>> To begin with the IntakeService has been refactored and works now in
>> a more hierarchal fashion. In the DefaultValidator there are rules
>> which *could* apply to all types of fields ie if it's required,
>> max/min length. There is then a NumberValidator with is concerned
>> with Rules applicable to all numbers afterwhich the different
>> numbers themselves and their specific rules.
>
>
> Yep, I understand all that - I quite like the newer structure.
>
>> For example if we look at an example for a String the following will
>> (should) work whereby we're setting required value to true. In your
>> example below you set it to false, perhaps that's why your not
>> getting the expected results.
>
>
> What I have is a field that is generally optional, but under some
> circumstances it becomes mandatory. In t2.2 the way this was done was
> to add a required-message element and to go
> group.get("GroupName").setRequired(true);
> and then
> group.isAllValid()
> would return false and the text of the required-message element would
> be assigned to the message of the field. This worked pretty well, but
> there was clearly an overlap between the required rule and the
> required-message element in that a required rule with a value of false
> ought to be able to supply the message text for the above scenario.
>
> With t2.3 the use of the required-message element produces the
> following in the log when intake.xml is parsed (the code that produces
> this message was added by Quinton, who I recall did a bunch of intake
> changes prior to you):
> 2003-09-18 08:51:21,563 WARN [Thread-6 ] transform.XmlToAppData -
> The required-message element is deprecated! You should update your
> intake.xml file to use the 'required' rule instead.
>
> This leads to the natural conclusion that the desired result should be
> achievable by using a required rule with a value of false, however
> this is not the case since the code has clearly not been updated to
> make this so.
>
> <snip>
>
>> I'll dig further into the DateString problem and get back to you with
>> a complete list of rules
>
>
> I have extracted the rules from the source, the problem is that the
> validator is not returning the date formatted according to the format
> rule. BTW: It might be interesting to at some stage provide for
> formatting numbers.
>
> Thanks for your reply.
>
> Cheers,
>
> Scott
>
Re: Intake bug: setRequired(true) does not display messages
Posted by Colin Chalmers <Co...@xs4all.nl>.
Hi Scott,
I've been looking into the DateString problem and know where the problem
lies, but unsure as to solution. I can offer you a workaround which
seems to work here but is NOT properly tested.
The problem lies in the fact that the Fields (ie DateStringField) return
an Object corresponding to their type in the getValue method. In our
case a Date Object is returned that has been initialised to that of the
input data. When the Date object is written to screen it shows the Date
correctly but NOT in the desired format. As you already know :-)
If you look into the Field class there are several properties that seem
to hold similiar information; testValue, validValue, emptyValue &
stringValue. This doesn't help things! But the stringValue is set to the
correct format!! and could/should? be returned from the getValue method
which from what I see is used for displaying data on screen. The setting
of properties on Object's using IntakeTool does not seem to utilise this
method.
<snip Field.java line 801>
val = stringValue; //getTestValue();
</snip>
Show's the data in the correct format.
However I am in two minds if the formatting of data belongs in the
IntakeService OR should be seperate in Localization/Internationalization
Tools?? Anyone got ideas on this??
I see that some of the Field classes are in need of refactoring, if
nothing else to simplify the use of some properties.
Colin
Scott Eade wrote:
> Colin Chalmers wrote:
>
>> To begin with the IntakeService has been refactored and works now in
>> a more hierarchal fashion. In the DefaultValidator there are rules
>> which *could* apply to all types of fields ie if it's required,
>> max/min length. There is then a NumberValidator with is concerned
>> with Rules applicable to all numbers afterwhich the different
>> numbers themselves and their specific rules.
>
>
> Yep, I understand all that - I quite like the newer structure.
>
>> For example if we look at an example for a String the following will
>> (should) work whereby we're setting required value to true. In your
>> example below you set it to false, perhaps that's why your not
>> getting the expected results.
>
>
> What I have is a field that is generally optional, but under some
> circumstances it becomes mandatory. In t2.2 the way this was done was
> to add a required-message element and to go
> group.get("GroupName").setRequired(true);
> and then
> group.isAllValid()
> would return false and the text of the required-message element would
> be assigned to the message of the field. This worked pretty well, but
> there was clearly an overlap between the required rule and the
> required-message element in that a required rule with a value of false
> ought to be able to supply the message text for the above scenario.
>
> With t2.3 the use of the required-message element produces the
> following in the log when intake.xml is parsed (the code that produces
> this message was added by Quinton, who I recall did a bunch of intake
> changes prior to you):
> 2003-09-18 08:51:21,563 WARN [Thread-6 ] transform.XmlToAppData -
> The required-message element is deprecated! You should update your
> intake.xml file to use the 'required' rule instead.
>
> This leads to the natural conclusion that the desired result should be
> achievable by using a required rule with a value of false, however
> this is not the case since the code has clearly not been updated to
> make this so.
>
> <snip>
>
>> I'll dig further into the DateString problem and get back to you with
>> a complete list of rules
>
>
> I have extracted the rules from the source, the problem is that the
> validator is not returning the date formatted according to the format
> rule. BTW: It might be interesting to at some stage provide for
> formatting numbers.
>
> Thanks for your reply.
>
> Cheers,
>
> Scott
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Intake bug: setRequired(true) does not display messages
Posted by Scott Eade <se...@backstagetech.com.au>.
Colin Chalmers wrote:
> To begin with the IntakeService has been refactored and works now in a
> more hierarchal fashion. In the DefaultValidator there are rules which
> *could* apply to all types of fields ie if it's required, max/min
> length. There is then a NumberValidator with is concerned with Rules
> applicable to all numbers afterwhich the different numbers themselves
> and their specific rules.
Yep, I understand all that - I quite like the newer structure.
> For example if we look at an example for a String the following will
> (should) work whereby we're setting required value to true. In your
> example below you set it to false, perhaps that's why your not getting
> the expected results.
What I have is a field that is generally optional, but under some
circumstances it becomes mandatory. In t2.2 the way this was done was
to add a required-message element and to go
group.get("GroupName").setRequired(true);
and then
group.isAllValid()
would return false and the text of the required-message element would be
assigned to the message of the field. This worked pretty well, but
there was clearly an overlap between the required rule and the
required-message element in that a required rule with a value of false
ought to be able to supply the message text for the above scenario.
With t2.3 the use of the required-message element produces the following
in the log when intake.xml is parsed (the code that produces this
message was added by Quinton, who I recall did a bunch of intake changes
prior to you):
2003-09-18 08:51:21,563 WARN [Thread-6 ] transform.XmlToAppData - The
required-message element is deprecated! You should update your
intake.xml file to use the 'required' rule instead.
This leads to the natural conclusion that the desired result should be
achievable by using a required rule with a value of false, however this
is not the case since the code has clearly not been updated to make this so.
<snip>
> I'll dig further into the DateString problem and get back to you with
> a complete list of rules
I have extracted the rules from the source, the problem is that the
validator is not returning the date formatted according to the format
rule. BTW: It might be interesting to at some stage provide for
formatting numbers.
Thanks for your reply.
Cheers,
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Intake bug: setRequired(true) does not display messages
Posted by Scott Eade <se...@backstagetech.com.au>.
Colin Chalmers wrote:
> To begin with the IntakeService has been refactored and works now in a
> more hierarchal fashion. In the DefaultValidator there are rules which
> *could* apply to all types of fields ie if it's required, max/min
> length. There is then a NumberValidator with is concerned with Rules
> applicable to all numbers afterwhich the different numbers themselves
> and their specific rules.
Yep, I understand all that - I quite like the newer structure.
> For example if we look at an example for a String the following will
> (should) work whereby we're setting required value to true. In your
> example below you set it to false, perhaps that's why your not getting
> the expected results.
What I have is a field that is generally optional, but under some
circumstances it becomes mandatory. In t2.2 the way this was done was
to add a required-message element and to go
group.get("GroupName").setRequired(true);
and then
group.isAllValid()
would return false and the text of the required-message element would be
assigned to the message of the field. This worked pretty well, but
there was clearly an overlap between the required rule and the
required-message element in that a required rule with a value of false
ought to be able to supply the message text for the above scenario.
With t2.3 the use of the required-message element produces the following
in the log when intake.xml is parsed (the code that produces this
message was added by Quinton, who I recall did a bunch of intake changes
prior to you):
2003-09-18 08:51:21,563 WARN [Thread-6 ] transform.XmlToAppData - The
required-message element is deprecated! You should update your
intake.xml file to use the 'required' rule instead.
This leads to the natural conclusion that the desired result should be
achievable by using a required rule with a value of false, however this
is not the case since the code has clearly not been updated to make this so.
<snip>
> I'll dig further into the DateString problem and get back to you with
> a complete list of rules
I have extracted the rules from the source, the problem is that the
validator is not returning the date formatted according to the format
rule. BTW: It might be interesting to at some stage provide for
formatting numbers.
Thanks for your reply.
Cheers,
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
Re: Intake bug: setRequired(true) does not display messages
Posted by Colin Chalmers <Co...@xs4all.nl>.
Hi Scott,
Apologies for the delay in getting back to you, been away to Belgium and
had to install new machine before even getting to Turbine stuff. I'll
try to answer a couple of your questions regarding the IntakeService,
I've also looked into the DateString problem and can at least reproduce
your problem. Did this ever work the way it should?? Anyway I'll look
into it further tomorrow with a clear head.
To begin with the IntakeService has been refactored and works now in a
more hierarchal fashion. In the DefaultValidator there are rules which
*could* apply to all types of fields ie if it's required, max/min
length. There is then a NumberValidator with is concerned with Rules
applicable to all numbers afterwhich the different numbers themselves
and their specific rules.
For example if we look at an example for a String the following will
(should) work whereby we're setting required value to true. In your
example below you set it to false, perhaps that's why your not getting
the expected results.
<snip>
<field name="ISBN" key="ISBNKey" type="String" mapToProperty="iSBN"
defaultValue="wooowoo">
<rule name="required" value="true">ISBN is a required field</rule>
<rule name="minLength" value="4">ISBN min length 4</rule>
<rule name="maxLength" value="9">ISBN max length 9</rule>
</field>
</snip>
We can build on this and define an integer field as follows, optionally
we could also add the min & max length rules. These rules belong to the
defaultvalidator and shall be validated BEFORE the specific rules for
integer itself, same applies to the required rule.
<snip>
<field name="ID" key="IDKey" type="int" mapToProperty="authorId"
defaultValue="6666">
<rule name="required" value="true">ID is a required field</rule>
<rule name="invalidNumber" value="true">ID NOT a number</rule>
<rule name="minValue" value="10010">ID min value 10010</rule>
<rule name="maxValue" value="888888888">ID max value
888888888</rule>
</field>
</snip>
I'll dig further into the DateString problem and get back to you with a
complete list of rules
HTH
Colin
An example
Scott Eade wrote:
> It seems that intake has a few bugs at present.
>
> 1. Colin is looking into the DateString problem.
> 2. I have committed Jürgen's patch to fix to the problem
> whereby empty fields were not being accepted even when
> required=false.
>
> I'm now running into a further problem whereby required
> messages are not being displayed when they should.
>
> This is a particular case where required=false in intake.xml:
>
> <field name="Amount" key="amt" type="BigDecimal">
> <rule name="required" value="false">Please enter a value.</rule>
> <rule name="minValue" value="0">Value must be >= 0.</rule>
> <rule name="maxValue" value="1000000">Please enter a more sensible
> value.</rule>
> <rule name="invalidNumber" value="true">The value entered must be a
> number.</rule>
> </field>
>
> but in my action I want to go:
>
> group.get("Amount").setRequired(true);
> if (!group.isAllValid())
> {
> return;
> }
>
> This worked previously and it still does when the now deprecated
> <required-message> element is included in the field. The
> recommended replacement of <required-message> is however the
> required rule that I have above.
>
> It seems that the current implementation of Field.setRequired()
> acts only upon the old required-message message which in my case
> is blank, thus I get an error that is not displayed!
>
> So I could in theory do the following in my action:
>
> ((DefaultValidator)
> group.get("Amount").getValidator()).setRequired(true);
>
> But this doesn't actually work. If it did then I would patch
> Field.setRequired() actually do this (I have the code, but since
> it doesn't work anyway there is no point committing it).
>
> I've spent as much time on this as I can afford to - the work
> around is to switch back to <required-message> for optional
> fields (which is what I would recommend since once fixed only
> intake.xml need be updated) or to go:
>
> group.get("Amount").setRequired(true,
> ((DefaultValidator)
> group.get("Amount").getValidator()).getRequiredMessage());
>
> which works, but is somewhat less than elegant :-)
>
> One further alternative would be to go:
>
> group.get("Amount").setRequired(true, "Enter a value!");
>
> But I the <required-message> solution will be the easiest to tidy
> up from once this is fixed.
>
> Needless to say the Intake documentation is way out of date -
> e.g. the "invalidNumber" rule is referred to as "notANumberMessage".
> and there is still no complete rule reference available.
> I'm not complaining - just pointing out a couple of shortcomings.
> If I had time I would have a go at updating these documents, but
> unfortunately I need to get back to some other pressing work.
>
> Scott
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Intake bug: setRequired(true) does not display messages
Posted by Scott Eade <se...@backstagetech.com.au>.
Scott Eade wrote:
> the work
> around is to switch back to <required-message> for optional
> fields (which is what I would recommend since once fixed only
> intake.xml need be updated)
Note that it appears that this workaround doesn't work for
BigDecimal fields (not sure about other numeric types).
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
Re: Intake bug: setRequired(true) does not display messages
Posted by Colin Chalmers <Co...@xs4all.nl>.
Hi Scott,
Apologies for the delay in getting back to you, been away to Belgium and
had to install new machine before even getting to Turbine stuff. I'll
try to answer a couple of your questions regarding the IntakeService,
I've also looked into the DateString problem and can at least reproduce
your problem. Did this ever work the way it should?? Anyway I'll look
into it further tomorrow with a clear head.
To begin with the IntakeService has been refactored and works now in a
more hierarchal fashion. In the DefaultValidator there are rules which
*could* apply to all types of fields ie if it's required, max/min
length. There is then a NumberValidator with is concerned with Rules
applicable to all numbers afterwhich the different numbers themselves
and their specific rules.
For example if we look at an example for a String the following will
(should) work whereby we're setting required value to true. In your
example below you set it to false, perhaps that's why your not getting
the expected results.
<snip>
<field name="ISBN" key="ISBNKey" type="String" mapToProperty="iSBN"
defaultValue="wooowoo">
<rule name="required" value="true">ISBN is a required field</rule>
<rule name="minLength" value="4">ISBN min length 4</rule>
<rule name="maxLength" value="9">ISBN max length 9</rule>
</field>
</snip>
We can build on this and define an integer field as follows, optionally
we could also add the min & max length rules. These rules belong to the
defaultvalidator and shall be validated BEFORE the specific rules for
integer itself, same applies to the required rule.
<snip>
<field name="ID" key="IDKey" type="int" mapToProperty="authorId"
defaultValue="6666">
<rule name="required" value="true">ID is a required field</rule>
<rule name="invalidNumber" value="true">ID NOT a number</rule>
<rule name="minValue" value="10010">ID min value 10010</rule>
<rule name="maxValue" value="888888888">ID max value
888888888</rule>
</field>
</snip>
I'll dig further into the DateString problem and get back to you with a
complete list of rules
HTH
Colin
An example
Scott Eade wrote:
> It seems that intake has a few bugs at present.
>
> 1. Colin is looking into the DateString problem.
> 2. I have committed Jürgen's patch to fix to the problem
> whereby empty fields were not being accepted even when
> required=false.
>
> I'm now running into a further problem whereby required
> messages are not being displayed when they should.
>
> This is a particular case where required=false in intake.xml:
>
> <field name="Amount" key="amt" type="BigDecimal">
> <rule name="required" value="false">Please enter a value.</rule>
> <rule name="minValue" value="0">Value must be >= 0.</rule>
> <rule name="maxValue" value="1000000">Please enter a more sensible
> value.</rule>
> <rule name="invalidNumber" value="true">The value entered must be a
> number.</rule>
> </field>
>
> but in my action I want to go:
>
> group.get("Amount").setRequired(true);
> if (!group.isAllValid())
> {
> return;
> }
>
> This worked previously and it still does when the now deprecated
> <required-message> element is included in the field. The
> recommended replacement of <required-message> is however the
> required rule that I have above.
>
> It seems that the current implementation of Field.setRequired()
> acts only upon the old required-message message which in my case
> is blank, thus I get an error that is not displayed!
>
> So I could in theory do the following in my action:
>
> ((DefaultValidator)
> group.get("Amount").getValidator()).setRequired(true);
>
> But this doesn't actually work. If it did then I would patch
> Field.setRequired() actually do this (I have the code, but since
> it doesn't work anyway there is no point committing it).
>
> I've spent as much time on this as I can afford to - the work
> around is to switch back to <required-message> for optional
> fields (which is what I would recommend since once fixed only
> intake.xml need be updated) or to go:
>
> group.get("Amount").setRequired(true,
> ((DefaultValidator)
> group.get("Amount").getValidator()).getRequiredMessage());
>
> which works, but is somewhat less than elegant :-)
>
> One further alternative would be to go:
>
> group.get("Amount").setRequired(true, "Enter a value!");
>
> But I the <required-message> solution will be the easiest to tidy
> up from once this is fixed.
>
> Needless to say the Intake documentation is way out of date -
> e.g. the "invalidNumber" rule is referred to as "notANumberMessage".
> and there is still no complete rule reference available.
> I'm not complaining - just pointing out a couple of shortcomings.
> If I had time I would have a go at updating these documents, but
> unfortunately I need to get back to some other pressing work.
>
> Scott
>