Try to trick it with dependencies.

$q->param( userid_untaint => 'dummy junk' );

my $dfv_profile =
{
    required    => [qw (userid_untaint)],
    dependencies => {
        userid_untaint => [ qw( userid ) ],
    },
    constraints    =>
    {
      userid =>
      {
          name          => 'userid_exists',
          constraint => sub { 
                return !MyDBITools->user_exists($ca_obj); },
      },
      userid_untaint =>
      {
          name         => 'userid_untaint',
          constraint => sub {
              my $tmp = $q->param( 'userid' );
              $tmp =~ s/^[-\@\w.]+$/;
              $q->param( userid => $tmp );
              },
      },
    },
    msgs =>
    {
        format        => '%s',
        constraints =>
        {
            'userid_exists' => "User ID already exists.",
            'userid_untaint'=> "User ID contains bad stuff",
        },
    },
};
[download]

The idea being to use a dummy constraint to do the untainting. This assumes that the module will perform the userid_untaint first because it's required, that will re-set the userid parameter with an untainted version, then dependencies will force the userid to be required also, then the module will run the userid validation which then performs the original function on the now untainted value.

I have no idea if this will actually work.

Why can't you untaint and check your database at the same time?

Bloody excellent, anon.

I never would have figured to do that clever trick. I tested it and it worked like a charm.

However I changed a few things from your suggested code to get exactly what I needed. I'm including them here in case others might want to use this ingenious tactic.

I reverted to my original regexp constraint for the userid_untaint constraint because I wanted users to know that they had entered invalid characters and didn't want the password silently changed, because then they wouldn't be able to log back in using their original password.

As well, I changed $q->param( userid_untaint => 'dummy junk' ); to $q->param( userid_untaint => $q->param('userid')); and took out the dependancy. Then I added both userid and userid_untaint to the required list. This way, the userid_untaint (I must change the name to something like userid2 or some such) becomes like an additional variable to be tested.

I'll ++ you tomorrow when I have some votes. Its a shame you are anon, because your excellent idea should be recognized.

Why can't you untaint and check your database at the same time?

I wanted a clear separation between each test to make it easier to send messages to the user and to make my code more maintainable. I included only a snippet of code in my OP, however, there are many more tests, including passord confirmation, email validation, etc. I am trying to take full advantage of the power of the D::FV module.

Many thanks,

Anne

I had a similar problem yesterday (and found this thread while doing a bit of research) but found an alternative solution in the module docs and thought I'd write it up here for the next time someone searches.

From the docs:

Multiple constraints can be applied to a single field by defining the value of the constraint to be an array reference.

I needed to (sort of) check the validity of an email address and make sure that the address' owner was not already registered.

To complicate matters a bit further, I needed to check that the entry in a field to confirm the email address matched.

Here's an abridged version of the form profile I used. It presupposes the existence of a Class::DBI derived package that knows about users:

my $profile = {

  required      => [ qw(

    user_name
    user_email
    user_email_confirm

    # more stuff here...

  ) ],

  msgs          => {

    prefix      => q[e_],
    constraints => {

      # helpful error messages:

      user_email_valid  => q[Invalid address],
      user_email_lookup => q[Already registered],
      emails_match      => q[Emails don't match],
    },
  },

  # tidy entries:

  filters       => ['trim','strip'],

  constraints   => {

    user_email            => [

      {
       name       => q[user_email_valid],
       constraint => q[email],
      },
      {
       name       => q[user_email_lookup],
       constraint => sub {

         # have a look in database:

         !My::Content::User->search(

           user_email => $_[0],
         );
       },
       params     => [ qw(

         user_email
       ) ],
      }
    ],

    user_email_confirm    => {

      name       => q[emails_match],
      constraint => sub { $_[0] eq $_[1] },
      params     => [ qw(

        user_email
        user_email_confirm
      ) ],
    },

    # more constraints, perhaps...
  },
};
[download]

HTH someone,

MB