1Validation::Class(3)  User Contributed Perl Documentation Validation::Class(3)
2
3
4

NAME

6       Validation::Class - Powerful Data Validation Framework
7

VERSION

9       version 7.900057
10

SYNOPSIS

12           use Validation::Class::Simple::Streamer;
13
14           my  $params = {username => 'admin', password => 's3cret'};
15           my  $input  = Validation::Class::Simple::Streamer->new(params => $params);
16
17           # check username parameter
18           $input->check('username')->required->between('5-255');
19           $input->filters([qw/trim strip/]);
20
21           # check password parameter
22           $input->check('password')->required->between('5-255')->min_symbols(1);
23           $input->filters([qw/trim strip/]);
24
25           # run validate
26           $input->validate or die $input->errors_to_string;
27

DESCRIPTION

29       Validation::Class is a scalable data validation library with interfaces
30       for applications of all sizes. The most common usage of
31       Validation::Class is to transform class namespaces into data validation
32       domains where consistency and reuse are primary concerns.
33       Validation::Class provides an extensible framework for defining
34       reusable data validation rules. It ships with a complete set of pre-
35       defined validations and filters referred to as "directives".
36
37       The core feature-set consist of self-validating methods, validation
38       profiles, reusable validation rules and templates, pre and post input
39       filtering, class inheritance, automatic array handling, and
40       extensibility (e.g. overriding default error messages, creating custom
41       validators, creating custom input filters and much more).
42       Validation::Class promotes DRY (don't repeat yourself) code. The main
43       benefit in using Validation::Class is that the architecture is designed
44       to increase the consistency of data input handling. The following is a
45       more traditional usage of Validation::Class, using the DSL to construct
46       a validator class:
47
48           package MyApp::Person;
49
50           use Validation::Class;
51
52           # data validation template
53           mixin basic     => {
54               required    => 1,
55               max_length  => 255,
56               filters     => [qw/trim strip/]
57           };
58
59           # data validation rules for the username parameter
60           field username  => {
61               mixin       => 'basic',
62               min_length  => 5
63           };
64
65           # data validation rules for the password parameter
66           field password  => {
67               mixin       => 'basic',
68               min_length  => 5,
69               min_symbols => 1
70           };
71
72           package main;
73
74           my $person = MyApp::Person->new(username => 'admin', password => 'secr3t');
75
76           # validate rules on the person object
77           unless ($person->validates) {
78               # handle the failures
79               warn $person->errors_to_string;
80           }
81
82           1;
83

QUICKSTART

85       If you are looking for a simple in-line data validation module built
86       using the same tenets and principles as Validation::Class, please
87       review Validation::Class::Simple or
88       Validation::Class::Simple::Streamer. If you are new to
89       Validation::Class, or would like more information on the underpinnings
90       of this library and how it views and approaches data validation, please
91       review Validation::Class::Whitepaper. Please review the "GUIDED-TOUR"
92       in Validation::Class::Cookbook for a detailed step-by-step look into
93       how Validation::Class works.
94

KEYWORDS

96   adopt
97       The adopt keyword (or adt) copies configuration and functionality from
98       other Validation::Class classes. The adopt keyword takes three
99       arguments, the name of the class to be introspected, and the
100       configuration type and name to be recreated. Basically, anything you
101       can configure using a Validation::Class keyword can be adopted into
102       other classes using this keyword with the exception of coderefs
103       registered using the build keyword. Please note! If you are adopting a
104       field declaration which has an associated mixin directive defined on
105       the target class, you must adopt the mixin explicitly if you wish it's
106       values to be interpolated.
107
108           package MyApp::Exployee;
109
110           use Validate::Class;
111           use MyApp::Person;
112
113           adopt MyApp::Person, mixin   => 'basic';
114           adopt MyApp::Person, field   => 'first_name';
115           adopt MyApp::Person, field   => 'last_name';
116           adopt MyApp::Person, profile => 'has_fullname';
117
118           1;
119
120   attribute
121       The attribute keyword (or has) registers a class attribute, i.e. it
122       creates an accessor (getter and setter) on the class. Attribute
123       declaration is flexible and only requires an attribute name to be
124       configured. Additionally, the attribute keyword can takes two
125       arguments, the attribute's name and a scalar or coderef to be used as
126       it's default value.
127
128           package MyApp::Person;
129
130           use Validate::Class;
131
132           attribute 'first_name' => 'Peter';
133           attribute 'last_name'  => 'Venkman';
134           attribute 'full_name'  => sub {
135               join ', ', $_[0]->last_name, $_[0]->first_name
136           };
137
138           attribute 'email_address';
139
140           1;
141
142   build
143       The build keyword (or bld) registers a coderef to be run at
144       instantiation much in the same way the common BUILD routine is used in
145       modern OO frameworks.
146
147           package MyApp::Person;
148
149           use Validation::Class;
150
151           build sub {
152
153               my ($self, $args) = @_;
154
155               # run after instantiation in the order defined
156
157           };
158
159           1;
160
161       The build keyword takes one argument, a coderef which is passed the
162       instantiated class object.
163
164   directive
165       The directive keyword (or dir) registers custom validator directives to
166       be used in your field definitions. Please note that custom directives
167       can only be used with field definitions. This is a means of extending
168       the list of directives per instance. See the list of core directives,
169       Validation::Class::Directives, or review Validation::Class::Directive
170       for insight into creating your own CPAN installable directives.
171
172           package MyApp::Person;
173
174           use Validate::Class;
175
176           # define a custom class-level directive
177           directive 'blacklisted' => sub {
178
179               my ($self, $field, $param) = @_;
180
181               if (defined $field->{blacklisted} && defined $param) {
182                   if ($field->{required} || $param) {
183                       if (exists_in_blacklist($field->{blacklisted}, $param)) {
184                           my $handle = $field->label || $field->name;
185                           $field->errors->add("$handle has been blacklisted");
186                           return 0;
187                       }
188                   }
189               }
190
191               return 1;
192
193           };
194
195           field 'email_address' => {
196               blacklisted => '/path/to/blacklist'
197               email => 1,
198           };
199
200           1;
201
202       The directive keyword takes two arguments, the name of the directive
203       and a coderef which will be used to validate the associated field. The
204       coderef is passed four ordered parameters; a directive object, the
205       class prototype object, the current field object, and the matching
206       parameter's value. The validator (coderef) is evaluated by its return
207       value as well as whether it altered any error containers.
208
209   document
210       The document keyword (or doc) registers a data matching profile which
211       can be used to validate heiarchal data. It will store a hashref with
212       pre-define path matching rules for the data structures you wish to
213       validate. The "path matching rules", which use a specialized object
214       notation, referred to as the document notation, can be thought of as a
215       kind-of simplified regular expression which is executed against the
216       flattened data structure. The following are a few general use-cases:
217
218           package MyApp::Person;
219
220           use Validation::Class;
221
222           field  'string' => {
223               mixin => [':str']
224           };
225
226           # given this JSON data structure
227           {
228               "id": "1234-A",
229               "name": {
230                   "first_name" : "Bob",
231                   "last_name"  : "Smith",
232                },
233               "title": "CIO",
234               "friends" : [],
235           }
236
237           # select id to validate against the string rule
238           document 'foobar'  =>
239               { 'id' => 'string' };
240
241           # select name -> first_name/last_name to validate against the string rule
242           document 'foobar'  =>
243               {'name.first_name' => 'string', 'name.last_name' => 'string'};
244
245           # or
246           document 'foobar'  =>
247               {'name.*_name' => 'string'};
248
249           # select each element in friends to validate against the string rule
250           document 'foobar'  =>
251               { 'friends.@'  => 'string' };
252
253           # or select an element of a hashref in each element in friends to validate
254           # against the string rule
255           document 'foobar'  =>
256               { 'friends.@.name' => 'string' };
257
258       The document declaration's keys should follow the aforementioned
259       document notation schema and it's values should be strings which
260       correspond to the names of fields (or other document declarations) that
261       will be used to preform the data validation. It is possible to combine
262       document declarations to validate hierarchical data that contains data
263       structures matching one or more document patterns. The following is an
264       example of what that might look like.
265
266           package MyApp::Person;
267
268           use Validation::Class;
269
270           # data validation rule
271           field  'name' => {
272               mixin      => [':str'],
273               pattern    => qr/^[A-Za-z ]+$/,
274               max_length => 20,
275           };
276
277           # data validation map / document notation schema
278           document 'friend' => {
279               'name' => 'name'
280           };
281
282           # data validation map / document notation schema
283           document 'person' => {
284               'name' => 'name',
285               'friends.@' => 'friend'
286           };
287
288           package main;
289
290           my $data = {
291               "name"   => "Anita Campbell-Green",
292               "friends" => [
293                   { "name" => "Horace" },
294                   { "name" => "Skinner" },
295                   { "name" => "Alonzo" },
296                   { "name" => "Frederick" },
297               ],
298           };
299
300           my $person = MyApp::Person->new;
301
302           unless ($person->validate_document(person => $data)) {
303               warn $person->errors_to_string if $person->error_count;
304           }
305
306           1;
307
308       Alternatively, the following is a more verbose data validation class
309       using traditional styling and configuration.
310
311           package MyApp::Person;
312
313           use Validation::Class;
314
315           field  'id' => {
316               mixin      => [':str'],
317               filters    => ['numeric'],
318               max_length => 2,
319           };
320
321           field  'name' => {
322               mixin      => [':str'],
323               pattern    => qr/^[A-Za-z ]+$/,
324               max_length => 20,
325           };
326
327           field  'rating' => {
328               mixin      => [':str'],
329               pattern    => qr/^\-?\d+$/,
330           };
331
332           field  'tag' => {
333               mixin      => [':str'],
334               pattern    => qr/^(?!evil)\w+/,
335               max_length => 20,
336           };
337
338           document 'person' => {
339               'id'                             => 'id',
340               'name'                           => 'name',
341               'company.name'                   => 'name',
342               'company.supervisor.name'        => 'name',
343               'company.supervisor.rating.@.*'  => 'rating',
344               'company.tags.@'                 => 'name'
345           };
346
347           package main;
348
349           my $data = {
350               "id"      => "1234-ABC",
351               "name"    => "Anita Campbell-Green",
352               "title"   => "Designer",
353               "company" => {
354                   "name"       => "House of de Vil",
355                   "supervisor" => {
356                       "name"   => "Cruella de Vil",
357                       "rating" => [
358                           {   "support"  => -9,
359                               "guidance" => -9
360                           }
361                       ]
362                   },
363                   "tags" => [
364                       "evil",
365                       "cruelty",
366                       "dogs"
367                   ]
368               },
369           };
370
371           my $person = MyApp::Person->new;
372
373           unless ($person->validate_document(person => $data)) {
374               warn $person->errors_to_string if $person->error_count;
375           }
376
377           1;
378
379       Additionally, the following is yet another way to validate a document
380       by passing the document specification directly instead of by name.
381
382           package MyApp::Person;
383
384           use Validation::Class;
385
386           package main;
387
388           my $data = {
389               "id"      => "1234-ABC",
390               "name"    => "Anita Campbell-Green",
391               "title"   => "Designer",
392               "company" => {
393                   "name"       => "House of de Vil",
394                   "supervisor" => {
395                       "name"   => "Cruella de Vil",
396                       "rating" => [
397                           {   "support"  => -9,
398                               "guidance" => -9
399                           }
400                       ]
401                   },
402                   "tags" => [
403                       "evil",
404                       "cruelty",
405                       "dogs"
406                   ]
407               },
408           };
409
410           my $spec = {
411               'id'                            => { max_length => 2 },
412               'name'                          => { mixin      => ':str' },
413               'company.name'                  => { mixin      => ':str' },
414               'company.supervisor.name'       => { mixin      => ':str' },
415               'company.supervisor.rating.@.*' => { pattern    => qr/^(?!evil)\w+/ },
416               'company.tags.@'                => { max_length => 20 },
417           };
418
419           my $person = MyApp::Person->new;
420
421           unless ($person->validate_document($spec => $data)) {
422               warn $person->errors_to_string if $person->error_count;
423           }
424
425           1;
426
427   ensure
428       The ensure keyword (or ens) is used to convert a pre-existing method
429       into an auto-validating method. The auto-validating method will be
430       registered and function as if it was created using the method keyword.
431       The original pre-existing method will be overridden with a modifed
432       version which performs the pre and/or post validation routines.
433
434           package MyApp::Person;
435
436           use Validation::Class;
437
438           sub register {
439               ...
440           }
441
442           ensure register => {
443               input  => ['name', '+email', 'username', '+password', '+password2'],
444               output => ['+id'], # optional output validation, dies on failure
445           };
446
447           package main;
448
449           my $person = MyApp::Person->new(params => $params);
450
451           if ($person->register) {
452               # handle the successful registration
453           }
454
455           1;
456
457       The ensure keyword takes two arguments, the name of the method to be
458       overridden and a hashref of required key/value pairs. The hashref may
459       have an input key (e.g. input, input_document, input_profile, or
460       input_method).  The `input` key (specifically) must have a value which
461       must be either an arrayref of fields to be validated, or a scalar value
462       which matches (a validation profile or auto-validating method name).
463       The hashref may also have an output key (e.g. output, output_document,
464       output_profile, or output_method).  The `output` key (specifically)
465       must have a value which must be either an arrayref of fields to be
466       validated, or a scalar value which matches (a validation profile or
467       auto-validating method name). Whether and what the method returns is
468       yours to decide. The method will return undefined if validation fails.
469       The ensure keyword wraps and functions much in the same way as the
470       method keyword.
471
472   field
473       The field keyword (or fld) registers a data validation rule for reuse
474       and validation in code. The field name should correspond with the
475       parameter name expected to be passed to your validation class or
476       validated against.
477
478           package MyApp::Person;
479
480           use Validation::Class;
481
482           field 'username' => {
483               required   => 1,
484               min_length => 1,
485               max_length => 255
486           };
487
488       The field keyword takes two arguments, the field name and a hashref of
489       key/values pairs known as directives. For more information on pre-
490       defined directives, please review the "list of core directives".
491
492       The field keyword also creates accessors which provide easy access to
493       the field's corresponding parameter value(s). Accessors will be created
494       using the field's name as a label having any special characters
495       replaced with an underscore.
496
497           # accessor will be created as send_reminders
498           field 'send-reminders' => {
499               length => 1
500           };
501
502       Please note that prefixing field names with a double plus-symbol
503       instructs the register to merge your declaration with any pre-existing
504       declarations within the same scope (e.g. fields imported via loading
505       roles), whereas prefixing field names with a single plus-symbol
506       instructs the register to overwrite any pre-existing declarations.
507
508           package MyApp::Person;
509
510           use Validation::Class;
511
512           set role => 'MyApp::User';
513
514           # append existing field and overwrite directives
515           field '++email_address' => {
516               required => 1
517           };
518
519           # redefine existing field
520           field '+login' => {
521               required => 1
522           };
523
524           1;
525
526   filter
527       The filter keyword (or flt) registers custom filters to be used in your
528       field definitions. It is a means of extending the pre-existing filters
529       declared by the "filters directive" before instantiation.
530
531           package MyApp::Person;
532
533           use Validate::Class;
534
535           filter 'flatten' => sub {
536               $_[0] =~ s/[\t\r\n]+/ /g;
537               return $_[0];
538           };
539
540           field 'biography' => {
541               filters => ['trim', 'strip', 'flatten']
542           };
543
544           1;
545
546       The filter keyword takes two arguments, the name of the filter and a
547       coderef which will be used to filter the value the associated field.
548       The coderef is passed the value of the field and that value MUST be
549       operated on directly.  The coderef should also return the transformed
550       value.
551
552   load
553       The load keyword (or set), which can also be used as a class method,
554       provides options for extending the current class by declaring roles,
555       requirements, etc.
556
557       The process of applying roles, requirement, and other settings to the
558       current class mainly involves introspecting the namespace's methods and
559       merging relevant parts of the prototype configuration.
560
561   load-classes
562       The `classes` (or class) option uses Module::Find to load all child
563       classes (in-all-subdirectories) for convenient access through the
564       "class" in Validation::Class::Prototype method, and when introspecting
565       a larger application. This option accepts an arrayref or single
566       argument.
567
568           package MyApp;
569
570           use Validation::Class;
571
572           load classes => ['MyApp::Domain1', 'MyApp::Domain2'];
573
574           package main;
575
576           my $app = MyApp->new;
577
578           my $person = $app->class('person'); # return a new MyApp::Person object
579
580           1;
581
582   load-requirements
583           package MyApp::User;
584
585           use Validate::Class;
586
587           load requirements => 'activate';
588
589           package MyApp::Person;
590
591           use Validation::Class;
592
593           load role => 'MyApp::User';
594
595           sub activate {}
596
597           1;
598
599       The `requirements` (or required) option is used to ensure that if/when
600       the class is used as a role the calling class has specific pre-existing
601       methods. This option accepts an arrayref or single argument.
602
603           package MyApp::User;
604
605           use Validate::Class;
606
607           load requirements => ['activate', 'deactivate'];
608
609           1;
610
611   load-roles
612           package MyApp::Person;
613
614           use Validation::Class;
615
616           load role => 'MyApp::User';
617
618           1;
619
620       The `roles` (or role) option is used to load and inherit functionality
621       from other validation classes. These classes should be used and
622       thought-of as roles although they can also be fully-functioning
623       validation classes. This option accepts an arrayref or single argument.
624
625           package MyApp::Person;
626
627           use Validation::Class;
628
629           load roles => ['MyApp::User', 'MyApp::Visitor'];
630
631           1;
632
633   message
634       The message keyword (or msg) registers a class-level error message
635       template that will be used in place of the error message defined in the
636       corresponding directive class if defined. Error messages can also be
637       overridden at the individual field-level as well. See the
638       Validation::Class::Directive::Messages for instructions on how to
639       override error messages at the field-level.
640
641           package MyApp::Person;
642
643           use Validation::Class;
644
645           field email_address => {
646               required   => 1,
647               min_length => 3,
648               messages   => {
649                   # field-level error message override
650                   min_length => '%s is not even close to being a valid email address'
651               }
652           };
653
654           # class-level error message overrides
655           message required   => '%s is needed to proceed';
656           message min_length => '%s needs more characters';
657
658           1;
659
660       The message keyword takes two arguments, the name of the directive
661       whose error message you wish to override and a string which will be
662       used to as a template which is feed to sprintf to format the message.
663
664   method
665       The method keyword (or mth) is used to register an auto-validating
666       method.  Similar to method signatures, an auto-validating method can
667       leverage pre-existing validation rules and profiles to ensure a method
668       has the required pre/post-conditions and data necessary for execution.
669
670           package MyApp::Person;
671
672           use Validation::Class;
673
674           method 'register' => {
675
676               input  => ['name', '+email', 'username', '+password', '+password2'],
677               output => ['+id'], # optional output validation, dies on failure
678               using  => sub {
679
680                   my ($self, @args) = @_;
681
682                   # do something registrationy
683                   $self->id(...); # set the ID field for output validation
684
685                   return $self;
686
687               }
688
689           };
690
691           package main;
692
693           my $person = MyApp::Person->new(params => $params);
694
695           if ($person->register) {
696
697               # handle the successful registration
698
699           }
700
701           1;
702
703       The method keyword takes two arguments, the name of the method to be
704       created and a hashref of required key/value pairs. The hashref may have
705       a `using` key whose value is the coderef to be executed upon successful
706       validation. The `using` key is only optional when a pre-existing
707       subroutine has the same name or the method being declared prefixed with
708       a dash or dash-process-dash. The following are valid subroutine names
709       to be called by the method declaration in absence of a `using` key.
710       Please note, unlike the ensure keyword, any pre-existing subroutines
711       will not be wrapped-and-replaced and can be executed without validation
712       if called directly.
713
714           sub _name {
715               ...
716           }
717
718           sub _process_name {
719               ...
720           }
721
722       The hashref may have an input key (e.g. input, input_document,
723       input_profile, or input_method). The `input` key (specifically) must
724       have a value which must be either an arrayref of fields to be
725       validated, or a scalar value which matches (a validation profile or
726       auto-validating method name), which will be used to perform data
727       validation before the aforementioned coderef has been executed. Whether
728       and what the method returns is yours to decide. The method will return
729       undefined if validation fails.
730
731           # alternate usage
732
733           method 'registration' => {
734               input  => ['name', '+email', 'username', '+password', '+password2'],
735               output => ['+id'], # optional output validation, dies on failure
736           };
737
738           sub _process_registration {
739               my ($self, @args) = @_;
740                   $self->id(...); # set the ID field for output validation
741               return $self;
742           }
743
744       Optionally the hashref may also have an output key (e.g. output,
745       output_document, output_profile, or output_method). The `output` key
746       (specifically) must have a value which must be either an arrayref of
747       fields to be validated, or a scalar value which matches (a validation
748       profile or auto-validating method name), which will be used to perform
749       data validation after the aforementioned coderef has been executed.
750
751       Please note that output validation failure will cause the program to
752       die, the premise behind this decision is based on the assumption that
753       given successfully validated input a routine's output should be
754       predictable and if an error occurs it is most-likely a program error as
755       opposed to a user error.
756
757       See the ignore_failure and report_failure attributes on the prototype
758       to control how method validation failures are handled.
759
760   mixin
761       The mixin keyword (or mxn) registers a validation rule template that
762       can be applied (or "mixed-in") to any field by specifying the mixin
763       directive. Mixin directives are processed first so existing field
764       directives will override any directives created by the mixin directive.
765
766           package MyApp::Person;
767
768           use Validation::Class;
769
770           mixin 'boilerplate' => {
771               required   => 1,
772               min_length => 1,
773               max_length => 255
774           };
775
776           field 'username' => {
777               # min_length, max_length, .. required will be overridden
778               mixin    => 'boilerplate',
779               required => 0
780           };
781
782       Since version 7.900015, all classes are automatically configured with
783       the following default mixins for the sake of convenience:
784
785           mixin ':flg' => {
786               required   => 1,
787               min_length => 1,
788               filters    => [qw/trim strip numeric/],
789               between    => [0, 1]
790           };
791
792           mixin ':num' => {
793               required   => 1,
794               min_length => 1,
795               filters    => [qw/trim strip numeric/]
796           };
797
798           mixin ':str' => {
799               required   => 1,
800               min_length => 1,
801               filters    => [qw/trim strip/]
802           };
803
804       Please note that the aforementioned mixin names are prefixed with a
805       semi-colon but are treated as an exception to the rule. Prefixing mixin
806       names with a double plus-symbol instructs the register to merge your
807       declaration with any pre-existing declarations within the same scope
808       (e.g. mixins imported via loading roles), whereas prefixing mixin names
809       with a single plus-symbol instructs the register to overwrite any pre-
810       existing declarations.
811
812           package MyApp::Moderator;
813
814           use Validation::Class;
815
816           set role => 'MyApp::Person';
817
818           # overwrite and append existing mixin
819           mixin '++boilerplate' => {
820               min_symbols => 1
821           };
822
823           # redefine existing mixin
824           mixin '+username' => {
825               required => 1
826           };
827
828           1;
829
830       The mixin keyword takes two arguments, the mixin name and a hashref of
831       key/values pairs known as directives.
832
833   profile
834       The profile keyword (or pro) registers a validation profile (coderef)
835       which as in the traditional use of the term is a sequence of validation
836       routines that validates data relevant to a specific action.
837
838           package MyApp::Person;
839
840           use Validation::Class;
841
842           profile 'check_email' => sub {
843
844               my ($self, @args) = @_;
845
846               if ($self->email_exists) {
847                   my $email = $self->fields->get('email');
848                   $email->errors->add('Email already exists');
849                   return 0;
850               }
851
852               return 1;
853
854           };
855
856           package main;
857
858           my $user = MyApp::Person->new(params => $params);
859
860           unless ($user->validate_profile('check_email')) {
861               # handle failures
862           }
863
864           1;
865
866       The profile keyword takes two arguments, a profile name and coderef
867       which will be used to execute a sequence of actions for validation
868       purposes.
869

METHODS

871   new
872       The new method instantiates a new class object, it performs a series of
873       actions (magic) required for the class to function properly, and for
874       that reason, this method should never be overridden. Use the build
875       keyword for hooking into the instantiation process.
876
877       In the event a foreign (pre-existing) `new` method is detected, an
878       `initialize_validator` method will be injected into the class
879       containing the code (magic) necessary to normalize your environment.
880
881           package MyApp::Person;
882
883           use Validation::Class;
884
885           # hook
886           build sub {
887
888               my ($self, @args) = @_; # on instantiation
889
890           };
891
892           sub new {
893
894               # rolled my own
895               my $self = bless {}, shift;
896
897               # execute magic
898               $self->initialize_validator;
899
900           }
901
902           1;
903
904   prototype
905       The prototype method (or proto) returns an instance of the associated
906       class prototype. The class prototype is responsible for manipulating
907       and validating the data model (the class). It is not likely that you'll
908       need to access this method directly, see Validation::Class::Prototype.
909
910           package MyApp::Person;
911
912           use Validation::Class;
913
914           package main;
915
916           my $person = MyApp::Person->new;
917
918           my $prototype = $person->prototype;
919
920           1;
921

PROXY METHODS

923       Validation::Class mostly provides sugar functions for modeling your
924       data validation requirements. Each class you create is associated with
925       a prototype class which provides the data validation engine and keeps
926       your class namespace free from pollution, please see
927       Validation::Class::Prototype for more information on specific methods
928       and attributes. Validation::Class injects a few proxy methods into your
929       class which are basically aliases to the corresponding prototype class
930       methods, however it is possible to access the prototype directly using
931       the proto/prototype methods.
932
933   class
934           $self->class;
935
936       See "class" in Validation::Class::Prototype for full documentation.
937
938   clear_queue
939           $self->clear_queue;
940
941       See "clear_queue" in Validation::Class::Prototype for full
942       documentation.
943
944   error_count
945           $self->error_count;
946
947       See "error_count" in Validation::Class::Prototype for full
948       documentation.
949
950   error_fields
951           $self->error_fields;
952
953       See "error_fields" in Validation::Class::Prototype for full
954       documentation.
955
956   errors
957           $self->errors;
958
959       See "errors" in Validation::Class::Prototype for full documentation.
960
961   errors_to_string
962           $self->errors_to_string;
963
964       See "errors_to_string" in Validation::Class::Prototype for full
965       documentation.
966
967   get_errors
968           $self->get_errors;
969
970       See "get_errors" in Validation::Class::Prototype for full
971       documentation.
972
973   get_fields
974           $self->get_fields;
975
976       See "get_fields" in Validation::Class::Prototype for full
977       documentation.
978
979   get_hash
980           $self->get_hash;
981
982       See "get_hash" in Validation::Class::Prototype for full documentation.
983
984   get_params
985           $self->get_params;
986
987       See "get_params" in Validation::Class::Prototype for full
988       documentation.
989
990   get_values
991           $self->get_values;
992
993       See "get_values" in Validation::Class::Prototype for full
994       documentation.
995
996   fields
997           $self->fields;
998
999       See "fields" in Validation::Class::Prototype for full documentation.
1000
1001   filtering
1002           $self->filtering;
1003
1004       See "filtering" in Validation::Class::Prototype for full documentation.
1005
1006   ignore_failure
1007           $self->ignore_failure;
1008
1009       See "ignore_failure" in Validation::Class::Prototype for full
1010       documentation.
1011
1012   ignore_intervention
1013           $self->ignore_intervention;
1014
1015       See "ignore_intervention" in Validation::Class::Prototype for full
1016       documentation.
1017
1018   ignore_unknown
1019           $self->ignore_unknown;
1020
1021       See "ignore_unknown" in Validation::Class::Prototype for full
1022       documentation.
1023
1024   is_valid
1025           $self->is_valid;
1026
1027       See "is_valid" in Validation::Class::Prototype for full documentation.
1028
1029   param
1030           $self->param;
1031
1032       See "param" in Validation::Class::Prototype for full documentation.
1033
1034   params
1035           $self->params;
1036
1037       See "params" in Validation::Class::Prototype for full documentation.
1038
1039   plugin
1040           $self->plugin;
1041
1042       See "plugin" in Validation::Class::Prototype for full documentation.
1043
1044   queue
1045           $self->queue;
1046
1047       See "queue" in Validation::Class::Prototype for full documentation.
1048
1049   report_failure
1050           $self->report_failure;
1051
1052       See "report_failure" in Validation::Class::Prototype for full
1053       documentation.
1054
1055   report_unknown
1056           $self->report_unknown;
1057
1058       See "report_unknown" in Validation::Class::Prototype for full
1059       documentation.
1060
1061   reset_errors
1062           $self->reset_errors;
1063
1064       See "reset_errors" in Validation::Class::Prototype for full
1065       documentation.
1066
1067   reset_fields
1068           $self->reset_fields;
1069
1070       See "reset_fields" in Validation::Class::Prototype for full
1071       documentation.
1072
1073   reset_params
1074           $self->reset_params;
1075
1076       See "reset_params" in Validation::Class::Prototype for full
1077       documentation.
1078
1079   set_errors
1080           $self->set_errors;
1081
1082       See "set_errors" in Validation::Class::Prototype for full
1083       documentation.
1084
1085   set_fields
1086           $self->set_fields;
1087
1088       See "set_fields" in Validation::Class::Prototype for full
1089       documentation.
1090
1091   set_params
1092           $self->set_params;
1093
1094       See "set_params" in Validation::Class::Prototype for full
1095       documentation.
1096
1097   set_method
1098           $self->set_method;
1099
1100       See "set_method" in Validation::Class::Prototype for full
1101       documentation.
1102
1103   stash
1104           $self->stash;
1105
1106       See "stash" in Validation::Class::Prototype for full documentation.
1107
1108   validate
1109           $self->validate;
1110
1111       See "validate" in Validation::Class::Prototype for full documentation.
1112
1113   validate_document
1114           $self->validate_document;
1115
1116       See "validate_document" in Validation::Class::Prototype for full
1117       documentation.
1118
1119   validate_method
1120           $self->validate_method;
1121
1122       See "validate_method" in Validation::Class::Prototype for full
1123       documentation.
1124
1125   validate_profile
1126           $self->validate_profile;
1127
1128       See "validate_profile" in Validation::Class::Prototype for full
1129       documentation.
1130

UPGRADE

1132       Validation::Class is stable, its feature-set is complete, and is
1133       currently in maintenance-only mode, i.e. Validation::Class will only be
1134       updated with minor enhancements and bug fixes. However, the lessons
1135       learned will be incorporated into a compelete rewrite uploaded under
1136       the namespace Validation::Interface.  The Validation::Interface fork is
1137       designed to have a much simpler API with less options and better
1138       execution, focused on validating hierarchical data as its primarily
1139       objective.
1140

EXTENSIBILITY

1142       Validation::Class does NOT provide method modifiers but can be easily
1143       extended with Class::Method::Modifiers.
1144
1145   before
1146           before foo => sub { ... };
1147
1148       See "before method(s) => sub { ... }" in Class::Method::Modifiers for
1149       full documentation.
1150
1151   around
1152           around foo => sub { ... };
1153
1154       See "around method(s) => sub { ... }" in Class::Method::Modifiers for
1155       full documentation.
1156
1157   after
1158           after foo => sub { ... };
1159
1160       See "after method(s) => sub { ... }" in Class::Method::Modifiers for
1161       full documentation.
1162

SEE ALSO

1164       Validation::Class does not validate blessed objects. If you need a
1165       means for validating object types you should use a modern object system
1166       like Moo, Mouse, or Moose. Alternatively, you could use decoupled
1167       object validators like Type::Tiny, Params::Validate or Specio.
1168

AUTHOR

1170       Al Newkirk <anewkirk@ana.io>
1171
1173       This software is copyright (c) 2011 by Al Newkirk.
1174
1175       This is free software; you can redistribute it and/or modify it under
1176       the same terms as the Perl 5 programming language system itself.
1177

POD ERRORS

1179       Hey! The above document had some coding errors, which are explained
1180       below:
1181
1182       Around line 1796:
1183           =back without =over
1184
1185
1186
1187perl v5.28.1                      2015-10-21              Validation::Class(3)
Impressum