Data::...esults(3pm)

πŸ“¦
version 4.88 Β· 4 versions
, in debian bookworm, debian trixie, ubuntu noble, ubuntu resolute, ubuntu stonking

πŸ’– Data::FormValidator::Results πŸ’–

okay bestie, listen up β€” this is the page for Data::FormValidator::Results, hanging out in the perl manual pages (that's the 3pm part, so you know it's a perl module thing). It's a results object. It tells you how your form validation went. That's the whole vibe. πŸŽ€


✨ NAME ✨

Data::FormValidator::Results β€” the receipts of your form input validation, fr fr. 🧾


🌈 SYNOPSIS 🌈

    my $results = Data::FormValidator->check(\%input_hash, \%dfv_profile);

    # Print the name of missing fields
    if ( $results->has_missing ) {
    for my $f ( $results->missing ) {
        print $f, " is missing\n";
    }
    }

    # Print the name of invalid fields
    if ( $results->has_invalid ) {
    for my $f ( $results->invalid ) {
        print $f, " is invalid: ", $results->invalid( $f ), "\n";
    }
    }

    # Print unknown fields
    if ( $results->has_unknown ) {
    for my $f ( $results->unknown ) {
        print $f, " is unknown\n";
    }
    }

    # Print valid fields
    for my $f ( $results->valid() ) {
        print $f, " =  ", $results->valid( $f ), "\n";
    }

πŸ’… DESCRIPTION πŸ’…

So basically: this object is what the Data::FormValidator check method hands back to you. It's the little gossip machine you query when you wanna know how the validation actually went down. Obsessed. ✨


πŸ‘‘ success();

Returns true if there were no invalid or missing fields β€” otherwise it returns false. Periodt.

And here's the cute part: when you use the $results object in boolean context, it's overloaded to just use the value of success() instead. Which means you can write iconic little syntax like this one, the exact one that CGI::Application::Plugin::ValidateRM uses:

 my $results = $self->check_rm('form_display','_form_profile') || return $self->dfv_error_page;

Main character energy honestly. 🫢


πŸ’– valid( [[field] [, value]] );

Depends entirely on how you call it, bestie. Here's the breakdown:

  • List context, no arguments β€” it hands you the list of fields that contain valid values:
 @all_valid_field_names = $r->valid;
  • Scalar context, no arguments β€” it hands you a hash reference where the valid fields are the keys and their input is the values:
 $all_valid_href = $r->valid;
  • One argument, scalar context β€” it returns the value of that field if it contains valid data, and undef if it doesn't. And heads up: the value will be an array ref if the field had multiple values:
 $value = $r->valid('field');
  • One argument, list context β€” it returns the values of field as an array:
 @values = $r->valid('field');
  • Two arguments β€” it sets field to value and returns value. This form is genuinely useful if you wanna alter the results from inside some constraints. Go peek at the Data::FormValidator::Constraints documentation for that one. πŸ‘€
 $new_value = $r->valid('field',$new_value);

πŸ¦‹ has_missing()

Returns true if the results contain missing fields. That's it, that's the whole method. πŸ’€


🌸 missing( [field] )

  • List context β€” returns the list of fields that are missing.
  • Scalar context β€” returns an array reference to the list of missing fields.
  • Called with an argument β€” returns true if that field is missing, and undef otherwise.

πŸ”₯ has_invalid()

Returns true if the results contain fields with invalid data. The drama detector. 😭


πŸŽ€ invalid( [field] )

  • List context β€” returns the list of fields which contain an invalid value.
  • Scalar context β€” returns a hash reference where the invalid fields are the keys, and references to arrays of failed constraints are the values.
  • Called with an argument β€” returns the reference to the array of failed constraints for field.

⭐ has_unknown()

Returns true if the results contain unknown fields. Sneaky little extras. πŸ™ˆ


πŸ’œ unknown( [field] )

  • List context β€” returns the list of fields which are unknown.
  • Scalar context β€” returns a hash reference containing the unknown fields and their values.
  • Called with an argument β€” returns the value of that field if it's unknown, and undef otherwise.

πŸ“ msgs([config parameters])

This one returns a hash reference to your error messages. The exact format is decided by the parameters in the msgs area of the validation profile β€” which is described over in the Data::FormValidator documentation. Go read that, iykyk. πŸ“š

NOTE: the msgs parameter in the profile can take a code reference as a value, which gives you complete control over how messages get generated. If a code reference was provided there, it gets called here instead of the usual processing described below. It will receive as arguments the Data::FormValidator::Results object and a hash reference of control parameters. Big power, use it wisely. ✨

The hashref you pass in should contain the same options you can define in the validation profile. This lets you separate the controls for message display from the rest of the profile. Because like β€” validation profiles may be different for every form, but you probably want your messages formatted the same way across many projects, right? Consistency is the vibe. πŸ’…

Controls passed into the <msgs> method get applied first, and then the ones applied in the profile come after. So you can keep the controls you pass to msgs as "global" and override them in a specific profile whenever you need to. Slay. πŸ‘‘


🧚 meta()

Sometimes a constraint stumbles across meta data that's useful to grab later. For example, when you're using Data::FormValidator::Constraints::Upload, several bits of meta data get discovered about files while they're being validated. These can include bytes, width, height and extension. The meta() function is what constraint methods use to set this data β€” and it's also what you use to access it. Here are some examples:

 # return all field names that have meta data
 my @fields = $results->meta();

 # To retrieve all meta data for a field:
 $meta_href = $results->meta('img');

 # Access a particular piece:
 $width = $results->meta('img')->{width};

And here's how you set some meta data. This is genuinely useful to know if you're out here writing your own complex constraint. πŸ› οΈ

    $self->meta('img', {
        width  => '50',
        height => '60',
    });
Heads up: this function does not currently support multi-valued fields. If it does in the future, the syntax above will still work. No cap. 🫑

🌟 SEE ALSO 🌟

  • Data::FormValidator
  • Data::FormValidator::Filters
  • Data::FormValidator::Constraints
  • Data::FormValidator::ConstraintsFactory

πŸ’Œ AUTHOR πŸ’Œ

Author: Francis J. Lacoste <francis.lacoste@iNsu.COM> Maintainer: Mark Stosberg <mark@summersault.com>


Copyright (c) 1999,2000 iNsu Innovations Inc. All rights reserved.

This program is free software; you can redistribute it and/or modify it under the terms as perl itself.


okay that's the whole page bestie, you're officially a Data::FormValidator::Results girlie now πŸ’– This little legend was brought to you by perl v5.34.0, dated 2022-06-12, and the page name is Data::...esults(3pm) in case you gotta cite your sources. bye bestie, go validate something πŸ’…βœ¨πŸ¦‹

πŸ“¦ where this page comes from