Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the HTML-FormHandler CPAN distribution.

Report information
The Basics
Id: 70871
Status: resolved
Priority: 0/
Queue: HTML-FormHandler

People
Owner: Nobody in particular
Requestors: JNWHITLEY [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in:
  • 0.35002
  • 0.35003
Fixed in: (no value)



Subject: Model::Object cannot cope with array multiple select in HTML::FormHandler::Widget::Field::Select
Download (untitled) / with headers
text/plain 2.3k
When using Model::Object, it appears that the default widget for the select list cannot cope with an array. This appears to be because the $optval test within the "find selected" test is assumed to be a scalar, which is correct for a single select field, but not a multiple one. This could be fixed in one of (at least) two places: * HTML::FormHandler::Widget::Field::Select * HTML::FormHandler::Widget::Field::Role::SelectedOption As HTML::FormHandler::Widget::Field::Select already has a test for whether this Select field is multiple, it seems sensible to place the additional work in this class. I've fixed this as by augmenting the code with a test for whether $optval is an arrayref, and adjusting the selected test accordingly. Here is the patch for the fix I implemented: diff HTML-FormHandler-0.35003/lib/HTML/FormHandler/Widget/Field/Select.pm patched/lib/HTML/FormHandler/Widget/Field/Select.pm 47,48c47,57 < $output .= ' selected="selected"' < if $self->check_selected_option($option, $optval); --- Show quoted text
> my $check_selected_option = undef; > if ('ARRAY' eq ref($optval)) { > foreach my $multiple_optval (@$optval) { > $check_selected_option =
$self->check_selected_option($option, $multiple_optval); Show quoted text
> last if ($check_selected_option); > } > } > else { > $check_selected_option =
$self->check_selected_option($option, $optval); Show quoted text
> } > $output .= ' selected="selected"' if
($check_selected_option); (diff -n) d47 2 a48 11 my $check_selected_option = undef; if ('ARRAY' eq ref($optval)) { foreach my $multiple_optval (@$optval) { $check_selected_option = $self->check_selected_option($option, $multiple_optval); last if ($check_selected_option); } } else { $check_selected_option = $self->check_selected_option($option, $optval); } $output .= ' selected="selected"' if ($check_selected_option);
Would it be possible for you to supply a test case?
Download (untitled) / with headers
text/plain 1.1k
Sorry for the delay in fixing this. There was an architectural problem with the way that setting 'selected/checked' in the options hashrefs was implemented. The "standard" way of doing that is to set defaults for that field, which is handled properly by the result construction methods (result_from_object, result_from_input, result_from_fields). The problem with setting that information in the options hashref is that when you get to the rendering phase, how do you know whether to use the defaults in the options? What if someone has submitted and there are now 'new' selections from input? You end up with a situation where the renderer has to know too much about context. I thought about just removing the ability to use options for that purpose, but people are using it and it is probably convenient for many cases. So I've changed the code in the Select field to set the defaults from the 'selected' or 'checked' keys in the options hashref. This feels a little roundabout, but avoids the architectural issues. So the widgets are no longer using the 'check_selected_option' method, since they are always set from 'fif' (fill-in-form). Please verify that this fix (currently in the repo) works for your case.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.