Custom Search
|
Date: April 29, 2005
From: Nathan Wiger <nate@xxxxxxx>
I deemed the few bugs severe enough (and easy enough to fix) that
I put together a bugfix release of CGI::FormBuilder 3.0201:
http://www.formbuilder.org/download/
The list of bugs fixed:
- missing $form->name accessor
- $form->confirm displaying wrong value for radio groups
- $form->new(messages => $file) not reading file
- added $form->field(delete => 1) option
- redone messages joiner on array passing (internals thing)
The changed files are:
CGI/FormBuilder.pm
CGI/FormBuilder/Field.pm
CGI/FormBuilder/Messages.pm
All other sub-modules shipped are identical to the 3.02 versions;
those modules retain the same version and signature.
Hope y'all have a good weekend...
-Nate
Date: April 28, 2005
From: "Liu, Aaron" <aaron.liu@xxxxxxxxxxxxxx>
Yes, it fixed the problem. Thanks for the quick patch.
> -----Original Message-----
> From: Nathan Wiger [mailto:nate@xxxxxxx]
> Sent: Thursday, April 28, 2005 02:09
> To: Liu, Aaron
> Cc: fbusers@xxxxxxxxxxxxxxx
> Subject: Re: Wrong caption for radio button group in static
> mode in FB 3.02
>
> Liu, Aaron wrote:
> >
> > The hidden value is correct, but the shown value is not
> (I think it
> > is just showing the first item in the radio group.) This is
> similar to
> > the drop down list case I think.
> >
> > Daitau Aaron
> >
>
> I believe I've isolated this already. Try the attached patch against
> Field.pm and let me know if it fixes it.
>
> I've added test cases to check for this in future releases.
>
> -Nate
>
Date: April 27, 2005
From: "Steve Knoblock (News Account)" <knoblock_private@xxxxxxxxxxxxxxxx>
In-reply-to:
<426FDA5C.5020609@xxxxxxx>
References:
<6CFE0AAEA0B7E84A9E6292B3A056A68D047A6493@xxxxxxxxxxxxxxxxxxxxxxx> <426EB2EA.4020106@xxxxxxx> <rjgt61lv336jcefq44vfrlthso5d3e1cn1@xxxxxxx> <426FDA5C.5020609@xxxxxxx>
On Wed, 27 Apr 2005 11:30:52 -0700, you wrote: >Steve Knoblock (News Account) wrote: >> Nate, >> here is a page from our mockups of our admin forms. All PHP of course, >> but you can look at the form. >> >> http://www.folkstreams.net/mockup/film-facts.html > >Another nice example. Like Jonas said, I thought I knew HTML. I must say >I see lots of potential use for that. I feel like a dummy for not using >those sooner. No, you shouldn't. Until recently most browser support was sketchy. I've used them for, I suppose, over a year or two in mockups, but was reticent to deploy them. Only IE supported them for a while. I only used them on folkstreams admin pages because we know who is using the pages. Fieldset groupings seem to be the rage now with blog tools. > > >Peter Eichman wrote: >> >> Brainstorming off of your brainstroming: >> >> I am assuming that if you listed a field name under the fields list in a >> fieldset, you would not need to duplicate it in a separate top-level >> fields list. > >At first glance that seems reasonable, but then I can think of lots of >situations where I define excess defaults/etc and then use 'fields' to >control which ones are actually shown. > >For example, check out this link and click on "Update it here!": > >http://www.beerlabels.com/labels/beers.pl?brewco=Dogfish-Head-Craft-Brewery&id=189 > >The mysql table has a bunch of other fields, but since you're not logged >in as an admin, they are just popped off the fields list (despite a full >hash of %prev_defs being passed to 'defaults'). Good idea. I may steal that. > >I'm wondering if the same could be done with 'fieldsets'. Maybe we >make it behave like validate/required: > > - If fields is NOT specified, then fieldsets is taken as the list > - If fields IS specified, then it overrides fieldsets > >> Also, how should fields without an associated fieldset >> behave in the presence of fieldsets? My inclination is to have them >> lumped together at the end; i.e., the builtin $form->render method >> would render the fieldsets first, then the "free-floating" fields. > >I would tend to agree. We could place them in an unnamed fieldset at the >bottom (ie no <legend>). Probably okay. I have not taken a look at how fields get generated, but I assume you intend iterate over the fields and could iterate over the mapping of fieldsets to fields instead. I'm still a little hazy on how this gets done. > >> How about also being able to give an optional prefix, to help >> cut down on typing. Taking the shipping/billing address example: >> >> CGI::FormBuilder->new( >> fieldsets => { >> saddr => { >> legend => 'Shipping Address', >> prefix => 'shipping_', >> fields => [qw(street city state zip)], >> }, > >Sounds cool, but I think at this point I want to resist too many more I like the idea. I typically end up doing a lot more typing creating different "namespace" for similar form sections like billing and shipping address info. It would be nice if they were prefixed with the fieldset prefix or even taken from the legend automatically. > fields => [ map { "shipping_$_" } > qw(street city state zip) ], Good enough. Steve Lead Developer www.folkstreams.net
Date: April 27, 2005
From: Nathan Wiger <nate@xxxxxxx>
In-reply-to:
<rjgt61lv336jcefq44vfrlthso5d3e1cn1@xxxxxxx>
References:
<6CFE0AAEA0B7E84A9E6292B3A056A68D047A6493@xxxxxxxxxxxxxxxxxxxxxxx> <426EB2EA.4020106@xxxxxxx> <rjgt61lv336jcefq44vfrlthso5d3e1cn1@xxxxxxx>
Steve Knoblock (News Account) wrote:
Nate, here is a page from our mockups of our admin forms. All PHP of course, but you can look at the form. http://www.folkstreams.net/mockup/film-facts.html
Another nice example. Like Jonas said, I thought I knew HTML. I must say I see lots of potential use for that. I feel like a dummy for not using those sooner. Peter Eichman wrote:
Brainstorming off of your brainstroming: I am assuming that if you listed a field name under the fields list in a fieldset, you would not need to duplicate it in a separate top-level fields list.
At first glance that seems reasonable, but then I can think of lots of situations where I define excess defaults/etc and then use 'fields' to control which ones are actually shown. For example, check out this link and click on "Update it here!": http://www.beerlabels.com/labels/beers.pl?brewco=Dogfish-Head-Craft-Brewery&id=189 The mysql table has a bunch of other fields, but since you're not logged in as an admin, they are just popped off the fields list (despite a full hash of %prev_defs being passed to 'defaults'). I'm wondering if the same could be done with 'fieldsets'. Maybe we make it behave like validate/required: - If fields is NOT specified, then fieldsets is taken as the list - If fields IS specified, then it overrides fieldsets
Also, how should fields without an associated fieldset behave in the presence of fieldsets? My inclination is to have them lumped together at the end; i.e., the builtin $form->render method would render the fieldsets first, then the "free-floating" fields.
I would tend to agree. We could place them in an unnamed fieldset at the bottom (ie no <legend>).
How about also being able to give an optional prefix, to help
cut down on typing. Taking the shipping/billing address example:
CGI::FormBuilder->new(
fieldsets => {
saddr => {
legend => 'Shipping Address',
prefix => 'shipping_',
fields => [qw(street city state zip)],
},
Sounds cool, but I think at this point I want to resist too many more
niceties. The 3.x series has too many bugs, and I really want it to
stabilize. I think we should just spell that like this:
CGI::FormBuilder->new(
fieldsets => {
saddr => {
legend => 'Shipping Address',
fields => [ map { "shipping_$_" }
qw(street city state zip) ],
},
Technically that's less typing too. :-)
-Nate
Date: April 27, 2005
From: Nathan Wiger <nate@xxxxxxx>
In-reply-to:
<E2A29F3F6CDDA14ABFDE8EA4FF280A740225A7F7@xxxxxxxxxxxxxxxxxxxxxxxx>
References:
<E2A29F3F6CDDA14ABFDE8EA4FF280A740225A7F7@xxxxxxxxxxxxxxxxxxxxxxxx>
Liu, Aaron wrote:
The hidden value is correct, but the shown value is not (I think it is just showing the first item in the radio group.) This is similar to the drop down list case I think. Daitau Aaron
I believe I've isolated this already. Try the attached patch against Field.pm and let me know if it fixes it.
I've added test cases to check for this in future releases. -Nate
--- CGI/FormBuilder/Field.pm 2005/04/27 17:58:19 1.40
+++ CGI/FormBuilder/Field.pm 2005/04/27 18:03:22
@@ -797,15 +797,17 @@
# if have options, lookup the label instead of the true value
for (@opt) {
my($o,$n) = optval($_);
- $n ||= $attr{labels}{$o} || ($self->nameopts ? toname($o) :
$o);
- $value = $n, last if $n;
+ if ($o eq $value) {
+ $n ||= $attr{labels}{$o} || ($self->nameopts ? toname($o)
: $o);
+ $value = $n;
+ last;
+ }
}
# print the value out too when in a static context, EXCEPT for
# manually hidden fields (those that the user hid themselves)
my $tagcom = escapehtml($value);
$tag .= $tagcom . ' ' if $self->static && $tagcom && $usertype ne
'hidden';
- debug 2, "if ", $self->static, " && $tagcom && $usertype ne
'hidden';";
if ($self->growable && $self->javascript) {
# put linebreaks between the input tags in growable fields
Date: April 27, 2005
From: Tom Wittbrodt <tomwitt2@xxxxxxxxx>
In-reply-to:
<426F89DF.4050903@xxxxxxxxxxx>
References:
<dd92bfff05042618457316b724@xxxxxxxxxxxxxx> <426F89DF.4050903@xxxxxxxxxxx>
Thanks everyone for your quick replies. This is just what I was looking for. -- Tom On 4/27/05, Peter Eichman <peichman@xxxxxxxxxxx> wrote: > Tom, > > There is a web version of the list at the gmane mailinglist to newsgroup > gateway, located at > http://news.gmane.org/gmane.comp.lang.perl.modules.formbuilder (it's > also available as a newsgroup if you point your newsreader to > news.gmane.org) > > It's not a complete archive, but it does go back before the beginning of > the framesets discussion. > > hth, > -Peter
Date: April 27, 2005
From: Peter Eichman <peichman@xxxxxxxxxxx>
In-reply-to:
<426EB2EA.4020106@xxxxxxx>
References:
<6CFE0AAEA0B7E84A9E6292B3A056A68D047A6493@xxxxxxxxxxxxxxxxxxxxxxx> <426EB2EA.4020106@xxxxxxx>
Nathan Wiger wrote:
Brainstorming in FB, I would say that: (a) fieldsets would have to be
named (like fields) and (b) that they would need a "legend" tag. Two
alternative syntaxes pop to mind:
CGI::FormBuilder->new(
fieldsets => { # or overload fields per Peter??
saddr => {
legend => 'Shipping Address',
fields => \@saddr_fields,
},
baddr => {
legend => 'Billing Address',
fields => \@baddr_fields,
}
},
);
AND/OR:
$form->fieldset(name => 'saddr', legend => 'Shipping Address',
fields => \@saddr_fields);
$form->fieldset(name => 'baddr', legend => 'Billing Address',
fields => \@baddr_fields);
Brainstorming off of your brainstroming:I am assuming that if you listed a field name under the fields list in a fieldset, you would not need to duplicate it in a separate top-level fields list. Also, how should fields without an associated fieldset behave in the presence of fieldsets? My inclination is to have them lumped together at the end; i.e., the builtin $form->render method would render the fieldsets first, then the "free-floating" fields.
How about also being able to give an optional prefix, to help cut down on typing. Taking the shipping/billing address example:
CGI::FormBuilder->new(
fieldsets => {
saddr => {
legend => 'Shipping Address',
prefix => 'shipping_',
fields => [qw(street city state zip)],
},
baddr => {
legend => 'Billing Address',
prefix => 'billing_',
fields => [qw(street city state zip)],
}
},
);
So your fields would end up being named shipping_street, shipping_city,
etc., and billing_street, billing_city, etc.
-Peter
Date: April 27, 2005
From: Peter Eichman <peichman@xxxxxxxxxxx>
In-reply-to:
<dd92bfff05042618457316b724@xxxxxxxxxxxxxx>
References:
<dd92bfff05042618457316b724@xxxxxxxxxxxxxx>
Tom,There is a web version of the list at the gmane mailinglist to newsgroup gateway, located at http://news.gmane.org/gmane.comp.lang.perl.modules.formbuilder (it's also available as a newsgroup if you point your newsreader to news.gmane.org)
It's not a complete archive, but it does go back before the beginning of the framesets discussion.
hth, -Peter Tom Wittbrodt wrote:
Does there exist a formbuilder mailing list archive other than http://www.formbuilder.org/archive/ (which seems to be empty)? Are there any user forums for formbuilder? I joined the mailing list in the midst of fieldset discussion that would appear to address the exact need I have and I'd like to see the prior messages in this thread. Thanks -- Tom
Date: April 27, 2005
From: Jonas Smedegaard <dr@xxxxxxxx>
Hi, I've found a bug in FB 3.02: The confirm() html page wrongly shows the first possible value instead of the selected one for popup-fields. The selected value is correctly send using mailresults(). More specificly, in the form at http://forms.dgi-huset.dk/skoleskema/ the popup-items with times and dates at the bottom are always acknowledged as 7:00-8:00, 1st january 2005 on the web confirmation but the email notification reports the chosen values. I reverted to 2.12 and it works fine again... If this info is not enough then tell me, and I'll isolate the case in a stripped-down script that I can publish here. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm
Date: April 27, 2005
From: Jonathan H N Chin <jc254fb@xxxxxxxxxxxxxxxx>
While people are asking about the list,
Something appears to have changed recently with the mailing list.
I have a procmail recipe that was working fine till a few days ago:
:0
* ^From fbusers.*@formbuilder.org
* ^Delivered-To: mailing list fbusers@xxxxxxxxxxxxxxx
pend/fbusers-list
but now there is no longer any Delivered-To: header, and the
From_ line on messages has changed to something like:
From nate@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Fri Apr 22 06:03:12 2005
So, list mail I receive is no longer being filtered properly.
Perhaps whoever maintains the list could arrange for some sort
of tag to be placed in the headers to facilitate matching.
I could probably match against a Received: header but that just
feels wrong (though I wouldn't be able to say why exactly).
thanks,
-jonathan
--
Jonathan H N Chin, 2 dan | deputy computer | Newton Institute, Cambridge, UK
<jc254@xxxxxxxxxxxxxxxx> | systems mangler | tel/fax: +44 1223 767091/330508
"respondeo etsi mutabor" --Rosenstock-Huessy
Date: April 27, 2005
From: "Liu, Aaron" <aaron.liu@xxxxxxxxxxxxxx>
Date: April 27, 2005
From: Tom Wittbrodt <tomwitt2@xxxxxxxxx>
Does there exist a formbuilder mailing list archive other than http://www.formbuilder.org/archive/ (which seems to be empty)? Are there any user forums for formbuilder? I joined the mailing list in the midst of fieldset discussion that would appear to address the exact need I have and I'd like to see the prior messages in this thread. Thanks -- Tom
Date: April 26, 2005
From: "Steve Knoblock (News Account)" <knoblock_private@xxxxxxxxxxxxxxxx>
In-reply-to:
<426EA326.6050806@xxxxxxx>
References:
<6CFE0AAEA0B7E84A9E6292B3A056A68D047A631F@xxxxxxxxxxxxxxxxxxxxxxx> <426EA326.6050806@xxxxxxx>
>This is where I get to display my ignorance: How do you use fieldsets >and legends? They are used to group fields into logical groups visually and label them. I think they are helpful and do not require a lot of table based layout gyrations that do the same thing. It seems fairly complex to track which fields belong to which fieldset, but if Nate thinks it is doable, okay. I was thinking more of just being able to specify the legend from the application. I work with templates and do not generate the forms (although I would probably like to given the work required to coordinate the code with the templates). Steve Lead Developer www.folkstreams.net
Date: April 26, 2005
From: Jonas Smedegaard <dr@xxxxxxxx>
In-reply-to:
<426EBBA6.6090602@xxxxxxx>
References:
<426EB38F.2030501@xxxxxxxx> <426EBBA6.6090602@xxxxxxx>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27-04-2005 00:07, Nathan Wiger wrote: > Yes, I think ::Mail would be a nice place for them, though I'm not sure > the best way to compartmentalize them to make them "pluggable". If > you've got suggestions I'm open. I'd suggest to leave the FormBuilder-specific mailresults() and mailconfirm() in the main FormBuilder, and move off mail() replaceable with Mail::Sendmail, Mail::Sender and probably Mail::SendEasy and others. > I'll also check out that messages issue; not sure why that's happening. Good. I have danish translation ready, and possibly will have other localisations ticking in if introducing it in a good way to Debian (especially the french translators are pretty active, but may not like to deal with non-gettext stuff). - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCbsDzn7DbMsAkQLgRAlouAJ9hHo4ZKsuLvg69XW41R8syozqLiwCeNZL7 pSHJ1+we1cyKDkb2a2BHtAI= =URUf -----END PGP SIGNATURE-----
Date: April 26, 2005
From: Jonas Smedegaard <dr@xxxxxxxx>
In-reply-to:
<6CFE0AAEA0B7E84A9E6292B3A056A68D047A6493@xxxxxxxxxxxxxxxxxxxxxxx>
References:
<6CFE0AAEA0B7E84A9E6292B3A056A68D047A6493@xxxxxxxxxxxxxxxxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26-04-2005 22:37, Randall, Michael P wrote: > The attached HTML file should give an idea of at least how I'm using > them. They look better with a stylesheet. Neat. I thought I knew HTML... :-) So now here's another live example: http://www.dgi-huset.dk/Booking_-_lokaler.htm - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCbrwLn7DbMsAkQLgRAvwXAKCZLPHxN6MtcCe7X/FPHmsrwySiVwCdGLJ/ kNIrJTZXT2tWdbb9TyEpD+Q= =AUp/ -----END PGP SIGNATURE-----
Date: April 26, 2005
From: Nathan Wiger <nate@xxxxxxx>
In-reply-to:
<426EB38F.2030501@xxxxxxxx>
References:
<426EB38F.2030501@xxxxxxxx>
I'll also check out that messages issue; not sure why that's happening. -Nate Jonas Smedegaard wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'd really appreciate it if the mail handling routines were moved off to a separate module, as I'd like to override it with with a proper MIME-handling backend like Mail::Sendmail but wouldn't want to reinvent mailresults() . It seems from comments in the code that you suspect nobody's using the mail parts of the module, so here's a notice that at least one person in the world does :-) . - Jonas
Date: April 26, 2005
From: Jonas Smedegaard <dr@xxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'd really appreciate it if the mail handling routines were moved off to a separate module, as I'd like to override it with with a proper MIME-handling backend like Mail::Sendmail but wouldn't want to reinvent mailresults() . It seems from comments in the code that you suspect nobody's using the mail parts of the module, so here's a notice that at least one person in the world does :-) . - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCbrOPn7DbMsAkQLgRAm+sAJ9AXccLEFYDq9D9/WzF+ZdR15YnWwCffJba lCtfFDVsGPWQuVkm5j9LhBA= =ZDQT -----END PGP SIGNATURE-----
Date: April 26, 2005
From: Nathan Wiger <nate@xxxxxxx>
In-reply-to:
<6CFE0AAEA0B7E84A9E6292B3A056A68D047A6493@xxxxxxxxxxxxxxxxxxxxxxx>
References:
<6CFE0AAEA0B7E84A9E6292B3A056A68D047A6493@xxxxxxxxxxxxxxxxxxxxxxx>
Randall, Michael P wrote:
The attached HTML file should give an idea of at least how I'm using them. They look better with a stylesheet.
Nice work, that looks really good. What else are you using other than FB? I'm curious.
Brainstorming in FB, I would say that: (a) fieldsets would have to be named (like fields) and (b) that they would need a "legend" tag. Two alternative syntaxes pop to mind:
CGI::FormBuilder->new(
fieldsets => { # or overload fields per Peter??
saddr => {
legend => 'Shipping Address',
fields => \@saddr_fields,
},
baddr => {
legend => 'Billing Address',
fields => \@baddr_fields,
}
},
);
AND/OR:
$form->fieldset(name => 'saddr', legend => 'Shipping Address',
fields => \@saddr_fields);
$form->fieldset(name => 'baddr', legend => 'Billing Address',
fields => \@baddr_fields);
What'd'ya think?
-Nate
Date: April 26, 2005
From: Jonas Smedegaard <dr@xxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, It seems referring to a file for translated messages is broken. I get the following error in Apache errorlog when (I believe) following the man page exactly: Can't locate object method "js_invalid_select" via package "messages.da_DK" (perhaps you forgot to load "messages.da_DK"?) at /usr/share/perl5/CGI/FormBuilder/Field.pm line 389. Also, looking quickly at the code it seems delimiter in the file must be space, not tabs or other whitespace. If I am correct in that, I propose extending to support any whitespace. - Jonas P.S. FormBuilder 3.02 should be in Debian "unstable" 24h from now. - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCbq6Ln7DbMsAkQLgRAoXkAJ9lNMJx5axupSajU/bN8uurtt413ACgqIYl GIgvp+cTHJfTpN9qeHmAQj8= =4r9H -----END PGP SIGNATURE-----
Date: April 26, 2005
From: "Randall, Michael P" <randall@xxxxxx>
The attached HTML file should give an idea of at least how I'm using them. They look better with a stylesheet. -----Original Message----- From: Nathan Wiger [mailto:nate@xxxxxxx] Sent: Tuesday, April 26, 2005 3:23 PM To: Randall, Michael P Cc: fbusers@xxxxxxxxxxxxxxx Subject: Re: Feature Request- "Separators" Randall, Michael P wrote: > 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 [snip] This is where I get to display my ignorance: How do you use fieldsets and legends? I personally have never had the need for anything outside of "standard" HTML fields - but maybe I've been missing out. Can you post an example to the list of good fieldset usage? It is worth noting that it is quite easy to write your own render engine with 3.02, and then say: $form->render(template => {type => 'My::Full::Module::Name'}); And you could cue off any tag you want, say: $form->field(name => 'me', fieldset => 'top'); # custom attr The only disadvantage to this method is you'll get an extraneous attr of fieldset="top" which validators will whine about. -Nate
Alternate Assessment ManagerBack to BeginningFrom here, you may edit the student data for the selected student. Fields that are highlighted are required. | ||
Date: April 26, 2005
From: Nathan Wiger <nate@xxxxxxx>
In-reply-to:
<6CFE0AAEA0B7E84A9E6292B3A056A68D047A631F@xxxxxxxxxxxxxxxxxxxxxxx>
References:
<6CFE0AAEA0B7E84A9E6292B3A056A68D047A631F@xxxxxxxxxxxxxxxxxxxxxxx>
Randall, Michael P wrote: > 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 [snip]This is where I get to display my ignorance: How do you use fieldsets and legends?
I personally have never had the need for anything outside of "standard" HTML fields - but maybe I've been missing out. Can you post an example to the list of good fieldset usage?
It is worth noting that it is quite easy to write your own render engine with 3.02, and then say:
$form->render(template => {type => 'My::Full::Module::Name'});
And you could cue off any tag you want, say:
$form->field(name => 'me', fieldset => 'top'); # custom attr
The only disadvantage to this method is you'll get an extraneous attr of
fieldset="top" which validators will whine about.
-Nate
Date: April 25, 2005
From: "Steve Knoblock (News Account)" <knoblock_private@xxxxxxxxxxxxxxxx>
In-reply-to:
<6CFE0AAEA0B7E84A9E6292B3A056A68D047A631F@xxxxxxxxxxxxxxxxxxxxxxx>
References:
<6CFE0AAEA0B7E84A9E6292B3A056A68D047A631F@xxxxxxxxxxxxxxxxxxxxxxx>
On Mon, 25 Apr 2005 08:38:54 -0500, you wrote: >fieldset-end. For something more complicated, I really understand using >templates or going with a new module. But, for something quick, I was thinking of adding placeholders for fieldset tags similar to the existing form-start, etc. You could have sectionname_legend that would display an assigned value. Of course, you could talk directly to the template. It's not that useful, but might help when using a language file to specify legend labels. The problem I see going in this direction is that it really does bring you closer to modeling the form as a whole. I can see that now. Headers, field groups, legends, even CFB's form start and end placeholders represent a level of abstraction above fields. So CFB already has its toe in the water, but to keep things simple, it may be better to avoid going off the deep end. Steve Lead Developer www.folkstreams.net
Date: April 25, 2005
From: "Randall, Michael P" <randall@xxxxxx>
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@xxxxxxx] Sent: Friday, April 22, 2005 3:28 PM To: Peter Eichman Cc: fbusers@xxxxxxxxxxxxxxx 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', > > # 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. In terms of an element model, it seems to me that if FB's API was truly "pluggable" (it's close but not quite), then one could use it just for creating fields, or even just messages, depending on what you wanted to do at the moment. I think it would be cool if there was a different module, say CGI::PageBuilder, that could do something like the above with catches in *its* new for FB fields: if ($type eq 'section') { push @gunk, CGI::Table->new(%whatever); if ($type eq 'field') { push @gunk, CGI::FormBuilder::Field->new(%whatever); } Thoughts? -Nate
Date: April 22, 2005
From: Nathan Wiger <nate@xxxxxxx>
In-reply-to:
<426882DF.8020006@xxxxxxxxxxx>
References:
<1114117148.26176.10.camel@collispuro
> <dieg61pq2chuvs5qn0isbem0fl53c78oo8@xxxxxxx> <426882DF.8020006@xxxxxxxxxxx>
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.
In terms of an element model, it seems to me that if FB's API was truly "pluggable" (it's close but not quite), then one could use it just for creating fields, or even just messages, depending on what you wanted to do at the moment. I think it would be cool if there was a different module, say CGI::PageBuilder, that could do something like the above with catches in *its* new for FB fields:
if ($type eq 'section') {
push @gunk, CGI::Table->new(%whatever);
if ($type eq 'field') {
push @gunk, CGI::FormBuilder::Field->new(%whatever);
}
Thoughts?
-Nate
Date: April 22, 2005
From: Peter Eichman <peichman@xxxxxxxxxxx>
In-reply-to:
<dieg61pq2chuvs5qn0isbem0fl53c78oo8@xxxxxxx>
References:
<1114117148.26176.10.camel@collispuro
> <dieg61pq2chuvs5qn0isbem0fl53c78oo8@xxxxxxx>
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 nice if some way could be found to get this logic into FB itself. I've been trying to think of ways to expand the scope of the FB model a little, but without disrupting the existing styles, calling conventions, etc.
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' },
],
(Seeing all this additional logic being packed in here, maybe this
should really be under a key like "model" or something, and preserve
"fields" with its current meaning)
One advantage I can see from this is that it would both leave open the possibility of defining new constructs in addition to sections and headings (groups of fields like {month, day, year} that could/should logically be rendered all on one line also come to mind) . The hashrefs would also allow for arbitrary keys that could be interpreted as HTML attributes (like with the current $form->field method).
Thoughts? -Peter Eichman
Date: April 22, 2005
From: "Liu, Aaron" <aaron.liu@xxxxxxxxxxxxxx>
> -----Original Message----- > From: Dan Collis Puro [mailto:dpuro@xxxxxxxxxxxxxx] > Sent: Friday, April 22, 2005 04:59 > To: fbusers@xxxxxxxxxxxxxxx > 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.
Date: April 22, 2005
From: "Steve Knoblock (News Account)" <knoblock_private@xxxxxxxxxxxxxxxx>
In-reply-to:
<1114117148.26176.10.camel@collispuro
>
References:
<1114117148.26176.10.camel@collispuro
>
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
Date: April 21, 2005
From: Nathan Wiger <nate@xxxxxxx>
In-reply-to:
<1114117148.26176.10.camel@collispuro
>
References:
<1114117148.26176.10.camel@collispuro
>
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.
-NateP.S. Just send it straight to me, and make it a diff -u off 3.02 (which is stable).
Date: April 21, 2005
From: Dan Collis Puro <dpuro@xxxxxxxxxxxxxx>
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 #######After $form->render <tr><td colspan=2 class='about_you'>About You</td></tr> <!-- form values here --> <tr><td colspan=2 class='where_live'>Where You Live</td></tr> <!-- more form values here -->
Date: April 20, 2005
From: Nathan Wiger <nate@xxxxxxx>
In-reply-to:
<BE8C40D0.13%chris.barrett@xxxxxxxxx>
References:
<BE8C40D0.13%chris.barrett@xxxxxxxxx>
$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
Date: April 20, 2005
From: Chris Barrett <chris.barrett@xxxxxxxxx>
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
Date: April 19, 2005
From: Nate Wiger <nwiger@xxxxxxxxx>
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