headers
Nate Wiger | 19 Apr 19:08
Picon
Gravatar

FormBuilder 3.02 on CPAN

CGI::FormBuilder 3.02 has been officially uploaded to CPAN,
as well as to formbuilder.org

This is a major release that fixes many bugs and also introduces
a lot of new features, most notably:

   - Multi-page form support
   - Per-field "other" and "growable" options
   - Autoloadable $field() subs (via fieldsubs option)
   - Ability to initialize FB from external config files
   - Addition of CGI::FastTemplate template engine
   - Character encoding dispatched to HTML::Entities
   - Easy plug-in support for CGI::Session
   - Truly subclassable template and messaging modules
   - Completely compliant XHTML output (validated)

You can download 3.02 at:

    http://www.formbuilder.org/download/

Many thanks to Peter Eichman for a ton of features and patches, and
Dr. Bob Egert for sponsoring much of the development of this version.

Enjoy,

Nate Wiger
FormBuilder Author
Permalink | Reply | 0 comments |
headers
Chris Barrett | 20 Apr 18:24

Multiple select options

Is there a method for adding attributes to items in a multiple select group?
At the moment, I have to pass an array to a template outside of FormBuilder
and use DOM to locate each select item and update them on the onLoad event.
(or similarly parse the generated HTML server side.)

Chris Barrett
Senior Engineer, Njini.com
Permalink | Reply | 1 comment |
headers
Nathan Wiger | 20 Apr 18:55
Picon

Re: Multiple select options

What type of attributes? You could pass common attributes that would be 
the same for each option tag:

     $form->field(name => 'mycheck',
                  type => 'checkbox',     # or whatever
                  options => \@optlist,
                  class => 'MyCheckBox',  # custom attr
                  useDB => 'YES');        # custom attr

(Also the id= tag will vary automatically for each checkbox)

But if you need different attrs for each option, then no.

-Nate

Chris Barrett wrote:
> Is there a method for adding attributes to items in a multiple select group?
> At the moment, I have to pass an array to a template outside of FormBuilder
> and use DOM to locate each select item and update them on the onLoad event.
> (or similarly parse the generated HTML server side.)
> 
> Chris Barrett
> Senior Engineer, Njini.com
> 
>
Permalink | Reply | 0 comments |
headers
Dan Collis Puro | 21 Apr 22:59
Picon

Feature Request- "Separators"

Nate and others,

I think it would be very handy to have a dummy field type called
"separator" that just puts a colspan'd row into the default table
output. . . Then it would be easy to "group" fields together logically
in the form.

I know this can be done with templates, but being able to just define a 
separator would help me a lot because I find I'm generating a whole slew
of forms programmatically.

I've wanted this for a while, seeing it implemented in PHP's
HTML_QuickForm kinda reminded me how useful this would be. If the module
is stable, I can look into a patch. . .

-DJCP

Something like:

********************
my $form=CGI::FormBuilder->new();

$form->field(type=>'separator',value=>'About You',class=>"about_you");
$form->field(name=>'first_name',label=>'Your First Name');
$form->field(name=>'last_name',label=>'Your Last Name');
$form->field(type=>'separator',value=>'Where you Live',
class=>'where_live');
$form->field(name=>'address_1',label=>'Address Line 1');
#More code
(Continue reading)

Permalink | Reply | 4 comments |
headers
Nathan Wiger | 22 Apr 00:44
Picon

Re: Feature Request- "Separators"

Dan Collis Puro wrote:
> Nate and others,
> 
> I think it would be very handy to have a dummy field type called
> "separator" that just puts a colspan'd row into the default table
> output. . . Then it would be easy to "group" fields together logically
> in the form.

An interesting idea, to nitpick the implementation (ultimately to make 
it easier), I would say:

     $form->field(name  => 'sep1',       # fields must have names
                  label => 'About You',  # instead of "value"
                  type  => 'separator',  # key
                  value => \@whatever,   # ignored
                  class => 'myClass');   # whatever else

Go ahead and look at a patch. This should be a simple change to ::Field 
in the tag() sub, maybe tag_value() to ignore a value if the type is 
'separator', and probably ::FormBuilder render() if you want to get the 
colspan => 2 thing in there.

-Nate

P.S. Just send it straight to me, and make it a diff -u off 3.02 (which 
is stable).
Permalink | Reply | 0 comments |
headers
Steve Knoblock (News Account | 22 Apr 02:32

Re: Feature Request- "Separators"

On Thu, 21 Apr 2005 16:59:08 -0400, you wrote:

>Nate and others,
>
>I think it would be very handy to have a dummy field type called
>"separator" that just puts a colspan'd row into the default table
>output. . . Then it would be easy to "group" fields together logically
>in the form.

Just wanted to mention, the FIELDSET and LEGEND elements are helpful
for grouping. I'd prefer support for those to any table based
solutions, although I am okay with supporting those given that CFB
renders using tables.

>I've wanted this for a while, seeing it implemented in PHP's
>HTML_QuickForm kinda reminded me how useful this would be. If the module
>is stable, I can look into a patch. . .

Thanks for mentioning that. I had not realized there was a PEAR form
handler available in a stable release. I note that the form object
models the entire form, not just fields, but that it models elements,
which appear to be any kind of form-part, such as fieldset or group
legend, heading, etc. potentially. I think CFB would have to expand
the scope of its model beyond form fields to achieve this.

Steve

Lead Developer
www.folkstreams.net
(Continue reading)

Permalink | Reply | 2 comments |
headers
Liu, Aaron | 22 Apr 03:47

RE: Feature Request- "Separators"

> -----Original Message-----
> From: Dan Collis Puro [mailto:dpuro <at> mindspring.com] 
> Sent: Friday, April 22, 2005 04:59
> To: fbusers <at> formbuilder.org
> Subject: Feature Request- "Separators"
> 
> Nate and others,
> 
> I think it would be very handy to have a dummy field type called
> "separator" that just puts a colspan'd row into the default table
> output. . . Then it would be easy to "group" fields together logically
> in the form.
> 

	Right now I make separator by (ab)using static type field:

$form->field(type=>'static',name=>'dummyheading',label=>'General
Information');

	With the new per field id it can be styled as a heading with
different colors, show/hide a whole section with javascript, etc.
Permalink | Reply | 0 comments |
headers
Peter Eichman | 22 Apr 06:51
Picon
Picon

Re: Feature Request- "Separators"

Steve Knoblock (News Account) wrote:
> On Thu, 21 Apr 2005 16:59:08 -0400, you wrote:
> 
>>Nate and others,
>>
>>I think it would be very handy to have a dummy field type called
>>"separator" that just puts a colspan'd row into the default table
>>output. . . Then it would be easy to "group" fields together logically
>>in the form.
> 
> Just wanted to mention, the FIELDSET and LEGEND elements are helpful
> for grouping. I'd prefer support for those to any table based
> solutions, although I am okay with supporting those given that CFB
> renders using tables.
<snip>
> Thanks for mentioning that. I had not realized there was a PEAR form
> handler available in a stable release. I note that the form object
> models the entire form, not just fields, but that it models elements,
> which appear to be any kind of form-part, such as fieldset or group
> legend, heading, etc. potentially. I think CFB would have to expand
> the scope of its model beyond form fields to achieve this.
> 

I use those elements (fieldset and legend) in the template in 
Text::FormBuilder. The formspec files it can parse can be divided into 
sections, each of which is rendered as a separate table within a 
fieldset (with an optional legend). There are also "headers", which are 
very similar to Dan's original "separator" suggestion.

Currently, these are implemented via a custom template, but it would be
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nathan Wiger | 22 Apr 22:28
Picon

Re: Feature Request- "Separators"

Peter Eichman wrote:
> Steve Knoblock (News Account) wrote:
> 
> It seems safe to say that any unmarked list of field names should 
> continue to be interpreted as it is currently. Perhaps hashrefs for the 
> new constructs?
> 
>     fields => [
>         # just a plain old field
>         'name',
> 
>         # a section
>         {
>             section => 'Contact Info',
>             fields => [qw(email phone fax)],
>         },
> 
>         # a heading
>         { heading => 'Important' },
>     ],

I worry this may be stretching FB past its usefulness. Personally, I 
think FB's big strength is its ability to shortcut stuff easily and play 
reasonably well with other modules.

Even now, having FB do stuff like title/header/body/etc is a bit much... 
but it's convenient for the easy cases. When you start getting into the 
above, I hate to sound like a broken record, but templates are really 
what we should be using.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randall, Michael P | 25 Apr 15:38
Favicon

RE: Feature Request- "Separators"

I don't think it is at all unreasonable for FormBuilder to support the
form tags fieldset and legend.  They are, after all, defined as form
tags in the HTML spec.  Also, it would make constructing longer forms
easier as it would not be necessary to construct a template in these
cases (having a long unbroken form is less than desirable).  To make it
simple, we could just have two new types: fieldset-start and
fieldset-end.  For something more complicated, I really understand using
templates or going with a new module.  But, for something quick,
fieldset support would be nice to have.

Thanks,
Mike

-----Original Message-----
From: Nathan Wiger [mailto:nate <at> sun.com] 
Sent: Friday, April 22, 2005 3:28 PM
To: Peter Eichman
Cc: fbusers <at> formbuilder.org
Subject: Re: Feature Request- "Separators"

Peter Eichman wrote:
> Steve Knoblock (News Account) wrote:
> 
> It seems safe to say that any unmarked list of field names should 
> continue to be interpreted as it is currently. Perhaps hashrefs for 
> the new constructs?
> 
>     fields => [
>         # just a plain old field
>         'name',
(Continue reading)

Permalink | Reply | 3 comments |

Gmane