Bug #63401 for Data-FormValidator: missing_optional

Sun Nov 28 07:16:53 2010 enquiries [...] mikeraynham.co.uk - Ticket created

Subject:

missing_optional_valid field list specification

Whilst Data::FormValidator is already great, I think it would be useful if it would optionally accept a list of fields for the 'missing_optional_valid' setting. A simple example of its use would be when creating or updating records in a database. When creating a row, the ID field will often not be supplied, but when updating a row, the ID field will be supplied: optional => [qw( id middle_name address_2 address_3 address_4 address_5 )], missing_optional_valid => [qw( middle_name address_2 address_3 address_4 address_5 )], In the above example, the id field would not be included in the valid hash, unless it has been given a valid value. I've attached a hastily tested patched version of Data::FormValidator::Results. See lines 376-390.

Mon Nov 29 09:58:41 2010 MARKSTOS [...] cpan.org - Taken

Mon Nov 29 10:00:37 2010 mark [...] summersault.com - Correspondence added

Subject:	Re: [rt.cpan.org #63401] missing_optional_valid field list specification
Date:	Mon, 29 Nov 2010 10:00:27 -0500
To:	bug-Data-FormValidator [...] rt.cpan.org
From:	Mark Stosberg <mark [...] summersault.com>

Show quoted text

> Whilst Data::FormValidator is already great, I think it would be useful > if it would optionally accept a list of fields for the > 'missing_optional_valid' setting. > > A simple example of its use would be when creating or updating records > in a database. When creating a row, the ID field will often not be > supplied, but when updating a row, the ID field will be supplied: > > optional => [qw( > id > middle_name > address_2 > address_3 > address_4 > address_5 > )], > > missing_optional_valid => [qw( > middle_name > address_2 > address_3 > address_4 > address_5 > )], > > In the above example, the id field would not be included in the valid > hash, unless it has been given a valid value.

Your case seems like it would be easily addressed by requiring the ID field for the edit case but not the add case. ( Just modify the profile hash dynamically for one case ). Show quoted text

> I've attached a hastily tested patched version of > Data::FormValidator::Results. See lines 376-390.

I'm sorry, no patch came through. Mark

Mon Nov 29 10:00:38 2010 The RT System itself - Status changed from 'new' to 'open'

Mon Nov 29 10:00:42 2010 MARKSTOS [...] cpan.org - Status changed from 'open' to 'stalled'

Mon Nov 29 10:22:51 2010 enquiries [...] mikeraynham.co.uk - Correspondence added

Subject:	Re: [rt.cpan.org #63401] missing_optional_valid field list specification
Date:	Mon, 29 Nov 2010 15:22:38 +0000
To:	bug-Data-FormValidator [...] rt.cpan.org
From:	Mike Raynham <enquiries [...] mikeraynham.co.uk>

On 29/11/10 15:00, mark@summersault.com via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=63401> >

>> Whilst Data::FormValidator is already great, I think it would be useful >> if it would optionally accept a list of fields for the >> 'missing_optional_valid' setting. >> >> A simple example of its use would be when creating or updating records >> in a database. When creating a row, the ID field will often not be >> supplied, but when updating a row, the ID field will be supplied: >> >> optional => [qw( >> id >> middle_name >> address_2 >> address_3 >> address_4 >> address_5 >> )], >> >> missing_optional_valid => [qw( >> middle_name >> address_2 >> address_3 >> address_4 >> address_5 >> )], >> >> In the above example, the id field would not be included in the valid >> hash, unless it has been given a valid value.

> > Your case seems like it would be easily addressed by requiring the ID > field for the edit case but not the add case. ( Just modify the profile > hash dynamically for one case ). >

>> I've attached a hastily tested patched version of >> Data::FormValidator::Results. See lines 376-390.

> > I'm sorry, no patch came through. > > Mark > >

Hi, Thanks for taking the time to respond. I agree that there are a few fairly simple ways to handle this. In this particular case, I'm using the presence or absence of the ID field to determine if an update or create is required, and passing the whole valid hash to the appropriate DBIx::Class method. At the moment I am just removing the ID field from the valid hash if its value is undefined, and this works well. I just thought that it may prove useful if it were possible to define which missing optional fields should be included (or perhaps excluded), rather than adjusting the profile hash, or post-processing the valid hash. I've attached my patched version. My apologies if it is a bit rubbish - I'm just starting out with Perl :-) Regards, Mike

Message body is not shown because sender requested not to inline it.

Mon Nov 29 10:22:52 2010 The RT System itself - Status changed from 'stalled' to 'open'

Mon Nov 29 10:34:26 2010 mark [...] summersault.com - Correspondence added

Subject:	Re: [rt.cpan.org #63401] missing_optional_valid field list specification
Date:	Mon, 29 Nov 2010 10:34:19 -0500
To:	bug-Data-FormValidator [...] rt.cpan.org
From:	Mark Stosberg <mark [...] summersault.com>

Show quoted text

> Thanks for taking the time to respond. I agree that there are a few > fairly simple ways to handle this. > > In this particular case, I'm using the presence or absence of the ID > field to determine if an update or create is required, and passing the > whole valid hash to the appropriate DBIx::Class method. At the moment I > am just removing the ID field from the valid hash if its value is > undefined, and this works well.

Mike, Thanks for the feedback, but I don't current intend to apply it. In your case, if the edit form accidentally falls to submit the ID field, then instead of an error message, you get a confusing "success" case, a row is inserted into the database! That's not a practice I want to encourage. Instead, if different add/edit run modes were used, you could modify the profile slightly for the edit case, and get a sensible error message if the edit field is missing. I leave missing_optional_valid=>1 turned on globally, all the time. I consider it a mistake that DFV didn't have this default, but the default has not been changed for backwards compatibility. That said, you find several other people on the DFV list that agree with your proposal, I'm happy to re-open the discussion. Mark

Mon Nov 29 10:34:51 2010 MARKSTOS [...] cpan.org - Status changed from 'open' to 'rejected'

Mon Nov 29 10:45:08 2010 enquiries [...] mikeraynham.co.uk - Correspondence added

Subject:	Re: [rt.cpan.org #63401] missing_optional_valid field list specification
Date:	Mon, 29 Nov 2010 15:44:57 +0000
To:	bug-Data-FormValidator [...] rt.cpan.org
From:	Mike Raynham <enquiries [...] mikeraynham.co.uk>

On 29/11/10 15:34, mark@summersault.com via RT wrote: Show quoted text

> Mike, > > Thanks for the feedback, but I don't current intend to apply it. In your > case, if the edit form accidentally falls to submit the ID field, then > instead of an error message, you get a confusing "success" case, a row > is inserted into the database! > > That's not a practice I want to encourage. Instead, if different > add/edit run modes were used, you could modify the profile slightly for > the edit case, and get a sensible error message if the edit field is > missing. > > I leave missing_optional_valid=>1 turned on globally, all the time. I > consider it a mistake that DFV didn't have this default, but the default > has not been changed for backwards compatibility. > > That said, you find several other people on the DFV list that agree with > your proposal, I'm happy to re-open the discussion. > > Mark >

Hi Mark, Okay, thanks for taking a look anyway. In this case, my form isn't handling the ID field, but I see your point. Regards, Mike

Mon Nov 29 10:45:09 2010 The RT System itself - Status changed from 'rejected' to 'open'

Bug #63401 for Data-FormValidator: missing_optional_valid field list specification

Maintainer(s)' notes