Form-Tiny

 view release on metacpan or  search on metacpan

lib/Form/Tiny/Manual/Compatibility.pod  view on Meta::CPAN

		type => Type,
		code => sub { ... },
	);

=head2 Input data is no longer deep cloned before validation

I<Changed in 2.01 - considered bugfix>

In previous versions, the validation process started off by deep cloning the
input by calling C<Storable::dclone> on it. It was unnecessary and had the
potential to lead to subtle bugs.

The validation process is cloning most of the input by itself by mangling
fields and then putting them back in the result hashref, much alike the input
one, but completely separate. However, if you specify that a field should be an
object of certain type, that will not get cloned. Same for explicit array and
hash references (not those specified as a path, like C<key1.key2>). Removing
deep cloning fixed that, as those would get cloned anyway.

So now, if you specify your field to contain something that is not a reference,
it will get cloned. If you specify something that is a reference, it will not
get cloned, and changing it will also change that single key in the input hash.
You have all the power to decide.

If you still want to deep clone your input data you can use the C<reformat>
hook for that. See L<Form::Tiny::Manual/"Hooks">.

=head2 Filtered forms no longer trim strings by default

I<Changed in 2.00>

In the past, declaring a form as filtered caused it to trim strings before
validation by default.

This behavior was removed due to difficulty in designing a sane interface that
would allow opting out of it. An exception of inline forms
(L<Form::Tiny::Inline>) was introduced, which still trim by default when
declared to be capable of filtering.

As this behavior is often needed, a keyword was introduced that allows to
enable it in a form:

	use Form::Tiny -filtered;
	form_trim_strings;

=head2 Sub-based form fields are resolved dynamically

I<Changed in 2.00>

In version I<2.00> a field definition which is built by a subroutine is called
a dynamic field, since it cannot be resolved in the form metaclass due to
access to form object as its first argument. Due to changes on where the field
definitions are stored, these subroutines are no longer ran once for each form
object, but rather multiple times, possibly even during a single validation
process.

This behavior is more correct, as class fields which you can access might
change between validations, and old field building would not take it into
account. However, it also means that subroutines that build form fields B<must
not> to contain any form of non-determinism (like random number generation) or
(to less degree) something variable in time (like datetime or access to busy
database entries).

I<Minor change in 2.03>

As of I<2.03>, the field definitions are still resolved dynamically, but will
keep their state until you trigger form reset by changing the input (with
C<set_input> method). This allows for some degree of randomness in forms, but
it will still change after you set different input. If you really want
randomness that will last for the entire lifetime of an object, regular class
attribute accessed in a dynamic field is your best bet:

	has 'random_field' => (
		is => 'ro',
		default => sub { rand },
	);

	form_field sub {
		my $self = shift;

		# access with $self->random_field;
	};

=head2 Dynamic (sub-based) form fields need to return a name

I<Changed in 2.00>

Previously, this syntax was allowed:

	form_field 'my_field' => sub {
		return {
			type => Int,
		};
	};

Due to changes on how form_field handles its arguments and how fields are
resolved, this now only accepts a subroutine reference, which in turn has to
return name explicitly:

	form_field sub {
		return {
			name => 'my_field',
			type => Int,
		};
	};

=head2 Hooks system has been overhauled

I<Changed in 2.00>

Previously, hooks were just a primitive system based on method overriding:

	sub pre_validate
	{
		my ($self, $data) = @_;

		...; # actual hook code
		return $data;
	}

This system was hard to handle and often buggy due to roles not copying methods



( run in 0.899 second using v1.01-cache-2.11-cpan-75ffa21a3d4 )