use Moose::Util::TypeConstraints;
use MooseX::Meta::TypeConstraint::Structured;
+use MooseX::Types::Structured::OverflowHandler;
use MooseX::Types -declare => [qw(Dict Tuple Optional)];
use Sub::Exporter -setup => { exports => [ qw(Dict Tuple Optional slurpy) ] };
+use Devel::PartialDump;
+use Scalar::Util qw(blessed);
-our $VERSION = '0.07';
+our $VERSION = '0.18';
our $AUTHORITY = 'cpan:JJNAPIORK';
=head1 NAME
],
);
+ ## Remainder of your class attributes and methods
+
Then you can instantiate this class with something like:
my $john = Person->new(
would fail, as well as ['hello', 111, 'world'] and so on. Here's another
example:
+ package MyApp::Types;
+
+ use MooseX::Types -declare [qw(StringIntOptionalHashRef)];
+ use MooseX::Types::Moose qw(Str Int);
+ use MooseX::Types::Structured qw(Tuple Optional);
+
subtype StringIntOptionalHashRef,
as Tuple[
Str, Int,
allow both null and undefined, you should use the core Moose 'Maybe' type
constraint instead:
+ package MyApp::Types;
+
use MooseX::Types -declare [qw(StringIntMaybeHashRef)];
- use MooseX::Types::Moose qw(Maybe);
+ use MooseX::Types::Moose qw(Str Int Maybe);
use MooseX::Types::Structured qw(Tuple);
subtype StringIntMaybeHashRef,
['World', 200];
Structured constraints are not limited to arrays. You can define a structure
-against a HashRef with 'Dict' as in this example:
+against a HashRef with the 'Dict' type constaint as in this example:
subtype FirstNameLastName,
as Dict[
lastname => Str,
];
-This would constrain a HashRef to something like:
+This would constrain a HashRef that validates something like:
- {firstname => 'Christopher', lastname= > 'Parsons'};
+ {firstname => 'Christopher', lastname => 'Parsons'};
but all the following would fail validation:
{firstname => 'Christopher', lastname => 'Parsons', middlename => 'Allen'};
## Not a HashRef
- ['Christopher', 'Christopher'];
+ ['Christopher', 'Parsons'];
These structures can be as simple or elaborate as you wish. You can even
combine various structured, parameterized and simple constraints all together:
ArrayRef[Int]
];
-Which would match "[1, {name=>'John', age=>25},[10,11,12]]". Please notice how
-the type parameters can be visually arranged to your liking and to improve the
-clarity of your meaning. You don't need to run then altogether onto a single
-line.
+Which would match:
+
+ [1, {name=>'John', age=>25},[10,11,12]];
+
+Please notice how the type parameters can be visually arranged to your liking
+and to improve the clarity of your meaning. You don't need to run then
+altogether onto a single line. Additionally, since the 'Dict' type constraint
+defines a hash constraint, the key order is not meaningful. For example:
+
+ subtype AnyKeyOrder,
+ as Dict[
+ key1=>Int,
+ key2=>Str,
+ key3=>Int,
+ ];
+
+Would validate both:
+
+ {key1 => 1, key2 => "Hi!", key3 => 2};
+ {key2 => "Hi!", key1 => 100, key3 => 300};
+
+As you would expect, since underneath its just a plain old Perl hash at work.
=head2 Alternatives
Tuple[Int,Str]; ## Validates [1,'hello']
Tuple[Str|Object, Int]; ## Validates ['hello', 1] or [$object, 2]
+The Values of @constraints should ideally be L<MooseX::Types> declared type
+constraints. We do support 'old style' L<Moose> string based constraints to a
+limited degree but these string type constraints are considered deprecated.
+There will be limited support for bugs resulting from mixing string and
+L<MooseX::Types> in your structures. If you encounter such a bug and really
+need it fixed, we will required a detailed test case at the minimum.
+
=head2 Dict[%constraints]
This defines a HashRef based constraint which allowed you to validate a specific
Dict[name=>Str, age=>Int]; ## Validates {name=>'John', age=>39}
+The keys in %constraints follow the same rules as @constraints in the above
+section.
+
=head2 Optional[$constraint]
This is primarily a helper constraint for Dict and Tuple type constraints. What
-this allows if for you to assert that a given type constraint is allowed to be
+this allows is for you to assert that a given type constraint is allowed to be
null (but NOT undefined). If the value is null, then the type constraint passes
but if the value is defined it must validate against the type constraint. This
makes it easy to make a Dict where one or more of the keys doesn't have to exist
{first=>'John', middle=>'James', last=>'Napiorkowski'}
{first=>'Vanessa', last=>'Li'}
+If you use the 'Maybe' type constraint instead, your values will also validate
+against 'undef', which may be incorrect for you.
+
=head1 EXPORTABLE SUBROUTINES
This type library makes available for export the following subroutines
=head2 slurpy
Structured type constraints by their nature are closed; that is validation will
-depend and an exact match between your structure definition and the arguments to
+depend on an exact match between your structure definition and the arguments to
be checked. Sometimes you might wish for a slightly looser amount of validation.
For example, you may wish to validate the first 3 elements of an array reference
and allow for an arbitrary number of additional elements. At first thought you
[10,"Hello", $obj, [11,12,13,...] ]; # Notice element 4 is an ArrayRef
In order to allow structured validation of, "and then some", arguments, you can
-use the </slurpy> method against a type constraint. For example:
+use the L</slurpy> method against a type constraint. For example:
use MooseX::Types::Structured qw(Tuple slurpy);
HashRef, also including other Dict constraints).
Please note the the technical way this works 'under the hood' is that the
-slurpy keywork transforms the target type constraint into a coderef. Please do
+slurpy keyword transforms the target type constraint into a coderef. Please do
not try to create your own custom coderefs; always use the slurpy method. The
underlying technology may change in the future but the slurpy keyword will be
supported.
+=head1 ERROR MESSAGES
+
+Error reporting has been improved to return more useful debugging messages. Now
+I will stringify the incoming check value with L<Devel::PartialDump> so that you
+can see the actual structure that is tripping up validation. Also, I report the
+'internal' validation error, so that if a particular element inside the
+Structured Type is failing validation, you will see that. There's a limit to
+how deep this internal reporting goes, but you shouldn't see any of the "failed
+with ARRAY(XXXXXX)" that we got with earlier versions of this module.
+
+This support is continuing to expand, so it's best to use these messages for
+debugging purposes and not for creating messages that 'escape into the wild'
+such as error messages sent to the user.
+
+Please see the test '12-error.t' for a more lengthy example. Your thoughts and
+preferable tests or code patches very welcome!
+
=head1 EXAMPLES
Here are some additional example usage for structured types. All examples can
And now you can instantiate with all the following:
__PACKAGE__->new(
- name=>'John Napiorkowski',
- age=>39,
+ person=>{
+ name=>'John Napiorkowski',
+ age=>39,
+ },
);
__PACKAGE__->new(
- first=>'John',
- last=>'Napiorkowski',
- years=>39,
+ person=>{
+ first=>'John',
+ last=>'Napiorkowski',
+ years=>39,
+ },
);
__PACKAGE__->new(
- fullname => {
- first=>'John',
- last=>'Napiorkowski'
+ person=>{
+ fullname => {
+ first=>'John',
+ last=>'Napiorkowski'
+ },
+ dob => 'DateTime'->new(
+ year=>1969,
+ month=>2,
+ day=>13
+ ),
},
- dob => 'DateTime'->new(
- year=>1969,
- month=>2,
- day=>13
- ),
);
This technique is a way to support various ways to instantiate your class in a
@$type_constraints : ();
my $overflow_handler;
- if(ref $type_constraints[-1] eq 'CODE') {
+ if($type_constraints[-1] && blessed $type_constraints[-1]
+ && $type_constraints[-1]->isa('MooseX::Types::Structured::OverflowHandler')) {
$overflow_handler = pop @type_constraints;
}
if(@values) {
my $value = shift @values;
unless($type_constraint->check($value)) {
+ $_[2]->{message} = $type_constraint->get_message($value)
+ if ref $_[2];
return;
}
} else {
## Test if the TC supports null values
unless($type_constraint->check()) {
+ $_[2]->{message} = $type_constraint->get_message('NULL')
+ if ref $_[2];
return;
}
}
## Make sure there are no leftovers.
if(@values) {
if($overflow_handler) {
- return $overflow_handler->([@values]);
+ return $overflow_handler->check([@values], $_[2]);
} else {
+ $_[2]->{message} = "More values than Type Constraints!"
+ if ref $_[2];
return;
}
} elsif(@type_constraints) {
- warn "I failed due to left over TC";
+ $_[2]->{message} =
+ "Not enough values for all defined type constraints. Remaining: ". join(', ',@type_constraints)
+ if ref $_[2];
return;
} else {
return 1;
@$type_constraints : ();
my $overflow_handler;
- if(ref $type_constraints[-1] eq 'CODE') {
+ if($type_constraints[-1] && blessed $type_constraints[-1]
+ && $type_constraints[-1]->isa('MooseX::Types::Structured::OverflowHandler')) {
$overflow_handler = pop @type_constraints;
}
my (%type_constraints) = @type_constraints;
my $value = $values{$key};
delete $values{$key};
unless($type_constraint->check($value)) {
+ $_[2]->{message} = $type_constraint->get_message($value)
+ if ref $_[2];
return;
}
} else {
## Test to see if the TC supports null values
unless($type_constraint->check()) {
+ $_[2]->{message} = $type_constraint->get_message('NULL')
+ if ref $_[2];
return;
}
}
## Make sure there are no leftovers.
if(%values) {
if($overflow_handler) {
- return $overflow_handler->(+{%values});
+ return $overflow_handler->check(+{%values});
} else {
+ $_[2]->{message} = "More values than Type Constraints!"
+ if ref $_[2];
return;
}
} elsif(%type_constraints) {
+ $_[2]->{message} =
+ "Not enough values for all defined type constraints. Remaining: ". join(', ',values %values)
+ if ref $_[2];
return;
} else {
return 1;
Moose::Util::TypeConstraints::add_parameterizable_type($Optional);
}
-sub slurpy($) {
- my $tc = shift @_;
- return sub {
- $tc->check(shift);
- };
+sub slurpy ($) {
+ my ($tc) = @_;
+ return MooseX::Types::Structured::OverflowHandler->new(
+ type_constraint => $tc,
+ );
}
=head1 SEE ALSO
Here's a list of stuff I would be happy to get volunteers helping with:
-All POD examples need test cases in t/documentation/*.t
-Want to break out the examples section to a separate cookbook style POD.
-Want more examples and best practice / usage guidance for authors
-Need to clarify deep coercions,
-Need to clarify subtypes of subtypes.
+ * All POD examples need test cases in t/documentation/*.t
+ * Want to break out the examples section to a separate cookbook style POD.
+ * Want more examples and best practice / usage guidance for authors
+ * Need to clarify deep coercions,
=head1 AUTHOR
-John Napiorkowski, C<< <jjnapiork@cpan.org> >>
+John Napiorkowski <jjnapiork@cpan.org>
+
+=head1 CONTRIBUTORS
+
+The following people have contributed to this module and agree with the listed
+Copyright & license information included below:
+
+ Florian Ragwitz, <rafl@debian.org>
+ Yuval Kogman, <nothingmuch@woobling.org>
=head1 COPYRIGHT & LICENSE
-This program is free software; you can redistribute it and/or modify
-it under the same terms as Perl itself.
+Copyright 2008-2009, John Napiorkowski <jjnapiork@cpan.org>
+
+This program is free software; you can redistribute it and/or modify it under
+the same terms as Perl itself.
=cut
projects / gitmo/MooseX-Types-Structured.git / blobdiff