We do something similar. Our validate hook is in 'respond_per_app' like so:

sub respond_per_app{
  my $self = shift;

  # If we validate, go ahead with page-specific items.
  return 0 if $self->param($self->config_state_param) and $self->valid
+ate();

  # If we are here, something failed, so re-render ourselves.
  return $self;
}
[download]

Our assumption is that if something failed in validation, we want to re-render the page we came from with an error message that tells the user what they did wrong. This should also give them back the bad params so they can see what they did wrong.

We then build the profile for Data::FormValidator on the fly based on the page we're on. The first part is set for the whole app like this:

sub validator_profile{

  # Set some app-wide values for the profile for Data::FormValidator.
  {
      validator_packages => [qw( My::Constraints )],
      msgs => { format => '%s',
                invalid_seperator => '!',
                constraints => \%My::constraint_msgs },
  };
}
[download]

Then in our config file, we have a hash with the constraint messages, and another that defines the required, optional, etc. fields. When the page loads, we have a 'load_attributes' method that builds out the profile. Then our validate method finalizes the profile and runs it through DFV. If anything fails, we load a data structure with errors to pass back to the template for display. These are displayed at the top of the page when we call ourselves again.

Building the profile and data structure for DFV is a little more work, but we've found many cases where dependencies are complex or there are extra params, so we can't just pass all params to DFV.