Custom validators with Rose::HTML::Form::Field::DateTime and its subclasses
Will Hawes
Rose::HTML::Form::Field::DateTime and its subclasses in order to
perform additional arbitrary checks on the submitted date - is it
within a specific range, or a specfic set of dates, does it fall on
the third Thursday of a month, etc.
However, Rose::HTML::Form::Field::DateTime::validate() currently
contains the following:
no warnings 'uninitialized';
if($self->input_value !~ /\S/)
{
my $ok = $self->SUPER::validate(@_);
return $ok unless($ok);
}
If a date field contains any data other than whitespace,
Rose::HTML::Form::Field::validate() is never called and the custom
validator is never fired.
I don't think just removing the regex check is the answer, as that
would run custom validation prior to having checked whether the value
is a valid date.
I've checked out the code and patched my working copy as follows:
1) Split Rose::HTML::Form::Field::validate() into validate() and
_validate() - the latter takes care of the "built in" validation for
the field, while the former calls _validate() and then the custom
validator if present.
2) Changed everything that previously subclassed validate() to
subclass _validate() instead (validate() is no longer overridden
anywhere), so the custom validator is always fired if present.
All existing tests still pass.
Is this of interest and if so would you like it committed back to the
repo (I'll need write access please) or posted here first?
Thanks.
John Siracusa
> I'd like to be able to use custom validators with
> Rose::HTML::Form::Field::DateTime and its subclasses in order to
> perform additional arbitrary checks on the submitted date - is it
> within a specific range, or a specfic set of dates, does it fall on
> the third Thursday of a month, etc.
As an aside, the best way to do this is probably by creating your own
field subclasses. Then you can do whatever you want in your
validate() methods. See the "private library" section of the
documentation for a comprehensive approach to subclassing:
http://search.cpan.org/dist/Rose-HTML-Objects/lib/Rose/HTML/Objects.pm#PRIVATE_LIBRARIES
> However, Rose::HTML::Form::Field::DateTime::validate() currently
> contains the following:
>
> no warnings 'uninitialized';
> if($self->input_value !~ /\S/)
> {
> my $ok = $self->SUPER::validate(@_);
> return $ok unless($ok);
> }
>
> If a date field contains any data other than whitespace,
> Rose::HTML::Form::Field::validate() is never called and the custom
> validator is never fired.
What I see in that code is, "If a field's input value does not contain
any non-whitespace characters, then call the superclass validate()
method, and if it returns false, return that false value." Calling
the superclass validate() should eventually lead to
Rose::HTML::Form::Field::validate(), no?
-John
Will Hawes
> http://search.cpan.org/dist/Rose-HTML-Objects/lib/Rose/HTML/Objects.pm#PRIVATE_LIBRARIES
Thanks for the pointer, I'd not seen that section of the docs
previously. I will have a read.
>> if($self->input_value !~ /\S/)
>> {
>> my $ok = $self->SUPER::validate(@_);
>> return $ok unless($ok);
>> }
>>
> What I see in that code is, "If a field's input value does not contain
> any non-whitespace characters, then call the superclass validate()
> method, and if it returns false, return that false value." Calling
> the superclass validate() should eventually lead to
> Rose::HTML::Form::Field::validate(), no?
Yes, for anything that doesn't match /\S/.
But given a value like '2009-09-01 03:14:56', which matches /\S/, the
superclass validate() is never called so nor is the custom validator.
So, it looks like I misunderstood the actual problem, which seems to
be that the date and time in my input value are separated by a space
rather than a 'T'.
Since both variations of the timestamp are common, would patching
R::H::F::F::DateTime to support either be more acceptable than my
initial suggestion?
Thanks.
John Siracusa
your problem.
-John
Will Hawes
>> So, it looks like I misunderstood the actual
>> problem, which seems to
>> be that the date and time in my input value are
>> separated by a space rather than a 'T'.
Sorry, that bit was completely wrong, either timestamp variant matches
/\S/ of course. Not sure what I was thinking there :/
> Try the version I just checked into SVN and let me know if it solves
> your problem.
Yes it does, thanks!