in reply to Re: Is there a way to set a textfield -name value at runtime?
in thread Is there a way to set a textfield -name value at runtime?

Thanks Eric...I have updated my posting with a standalone test case of what I'm trying to do. The two blocks of code in the main posting relate to each other like this:

- The %options hash has a set of cgi objects (i.e. checkboxes, textfields, radio buttons) that I want to be able to select from as sub-options for a given top-level radio button.

- Each key of %report_types points to a hashref that defines the properties of that particular report: its name (name), its sub-options (opts), and its generator (coderef).

Since there are two reports defined, each of which has a "date" textfield as a sub-option, I'd like to name these textfields according to the report type (i.e. "date_1" and "date_2"). But since the "date" textfield is defined once in the %options hash, I don't see how to do this.

Update: I just realized that I can probably do what I want by making my own Reports class, creating instances at runtime with the necessary sub-options. The names of the textfields can then be assigned unique values by passing in an appropriate parameter during the instance construction.

  • Comment on Re^2: Is there a way to set a textfield -name value at runtime?

Replies are listed 'Best First'.
Re^3: Is there a way to set a textfield -name value at runtime?
by eric256 (Parson) on Jan 26, 2008 at 04:47 UTC

    A little formating goes a long way for clarity here:

    my %options = ( show_reqs => checkbox( -name => 'show_reqids', -checked => 0, -value => 'ON', -label => 'Show requirement + IDs?'), date => "<b>Created: </b>" . radio_group( -name=>'bef_since', -values=>['before', 'since'], -default=>'none', -labels => {'before' => 'b +efore ', 'since' => 's +ince (inclusive)'} ) . "&nbsp;&nbsp;<b>Date</b> (YYYY-MM-DD +): " . textfield(-name=>'date', -size=>10, +-maxlength=>10), req_type => "<b>Requirement Type</b> (e.g. BRQ): " . textfield( -name => 'reqtype', -size => 5, -maxlength=>5), ); my %report_types = ( 0 => { name => "Project Requirements: Filtered by +Creation Date", opts => ['show_reqs', 'date'], coderef => \&report_type_two }, 1 => { name => "Project Requirement Revisions: Fil +tered by Creation Date, Type, and Version Reason", opts => ['show_reqs', 'req_type', 'date'], coderef => \&report_type_three}, );

    It is now more obvious that you are generating the actual elements a little soon. I would make the options sub refs that take the report name as an argument (and possibly more) so that you could create unique instances. At least they should take the fields own name as an argument. I think the following will be close:

    my %options = ( show_reqs => sub { my $report = shift; return checkbox( -name => $report . '_show_ +reqids', -checked => 0, -value => 'ON', -label => 'Show requirement + IDs?'), } ); print $options{$option}->($report), "\n";

    In this manner your options are constructors. They could even take in more arguments, like default values or something, so that each report could have different defaults.


    ___________
    Eric Hodges