Marie Shvartsapel | 15 Mar 06:22
Favicon

HTML::Template + validation = strange behavior?

Hello,

I'm new to the FormBuilder and to this list, so please excuse me if this has
been discussed already.
I am trying to use HTML::Template template + validation functionality of the
FB. I turned off JavaScript and want to use server side validation only.

Let me describe the scenario in short: Form is displayed, submitted (with
blank fields), redisplayed with error messages, submitted again (again with
blank values). Now the fun part: All of my visible form elements get
doubled!

     Am I not using FB or template correctly or this is "a feature" of FB?

Ok, a little clarification - it seems to be happening when I leave the field
blank without trying to fill it in, just submit it again , whereas this
problem does not seem to occur when some other not-empty invalid value was
provided and left unchanged...
I agree that this is not very typical usage, but hey, you can overlook one
of the values if you are working with a long form.
I have created very simple test script to make sure nothing else gets in the
way.

You can test it for yourself here:
http://maries.thecsl.org/cgi-bin/clearinghouse/test.pl (see code below)

Another detail - I'm using "keepextras"set to 1. Not sure if this might be
related.

A little bonus question: Is my understanding correct that I have to
(Continue reading)

Liu, Aaron | 15 Mar 07:25

Suggestion for indivdual field scripting/styling

Hi,
 
    Despite Nathan's repeated advices on not to use the built-in rendering when one needs flexibility in various parts of the document, I have found the built-in rendering quite sufficient for my usage, with one exception: I need to be able to address individual fields's containing row (<tr>) by id. With individual id assigned to the table rows I can easily show and hide fields by javascript at run-time. I can also highlight fields I need by applying style to individual fields I needed. So far I have hacked the code (for version 2) to include ths id so an input field named "password" would be enclosed within a <tr id="tr_password" ... >. Do you think this feature can be included in version 3 or am I just too lazy and should switch to templates instead? (Or it was already in version 3 and I missed it?) Any comments are welcome.
 
Aaron
 
Marie Shvartsapel | 15 Mar 17:18
Favicon

Re: HTML::Template + validation = strange behavior?; Custom messages?

Update:
    setting "keepextras" to 0 seems to fix it. But I need to use 
keepextras because I'm using it for keeping "mode" parameter...(as 
recommended in *Advanced Tutorial - Step 9: Multi-Screen Apps 3 @ 
FormBuilder.org)
*   
One more question:
       I'm trying to change default messages, specifically the tag  that 
wraps around error messages.  I'm passing  the hash to the FB's new() 
method, as shown in the docs:
            messages => {
                form_invalid_opentag => '<span style="color: red">',
                form_invalid_closetag => '</span>'
            },
It does not have any effect for me.
Can anyone spot my mistake?

Thanks for your help,
Marie

Marie Shvartsapel wrote:

>Hello,
>
>I'm new to the FormBuilder and to this list, so please excuse me if this has
>been discussed already.
>I am trying to use HTML::Template template + validation functionality of the
>FB. I turned off JavaScript and want to use server side validation only.
>
>Let me describe the scenario in short: Form is displayed, submitted (with
>blank fields), redisplayed with error messages, submitted again (again with
>blank values). Now the fun part: All of my visible form elements get
>doubled!
>
>     Am I not using FB or template correctly or this is "a feature" of FB?
>
>Ok, a little clarification - it seems to be happening when I leave the field
>blank without trying to fill it in, just submit it again , whereas this
>problem does not seem to occur when some other not-empty invalid value was
>provided and left unchanged...
>I agree that this is not very typical usage, but hey, you can overlook one
>of the values if you are working with a long form.
>I have created very simple test script to make sure nothing else gets in the
>way.
>
>You can test it for yourself here:
>http://maries.thecsl.org/cgi-bin/clearinghouse/test.pl (see code below)
>
>Another detail - I'm using "keepextras"set to 1. Not sure if this might be
>related.
>
>A little bonus question: Is my understanding correct that I have to
>explicitly include "<tmpl_var error-name1>" into my template if I want error
>messages to be displayed? Originally I thought that <tmpl_var field-name1>
>will take care of error msgs for me....
>
>Thanks in advance, I really hope to get this resolved...
>-Marie.
>
>Script code:
>#!/usr/bin/perl
>use strict;
>use warnings;
>use CGI::FormBuilder;
>my $form=CGI::FormBuilder->new(
> fields => [qw(name1 name2)],
> method => 'post',
>       template => 'temp.temp',
>       validate => {
>   name1=>'NAME',
>   name2=>'NUM'
>  },
> header=>1,
> keepextras=>1,
> javascript=>0
>);
>if ($form->submitted && $form->validate){
> print "Content-type: text/html\n\nThe submition is valid";
>}else{
> print $form->render;
>}
>
>Template code:
><html>
><body>
><tmpl_var form-start>
>Name<tmpl_var field-name1><tmpl_var error-name1><br>
>Number<tmpl_var field-name2><tmpl_var error-name2><br>
><tmpl_var form-submit>
><tmpl_var form-end>
></body>
></html>
>
>
>  
>

--

-- 
AmeriCorps VISTA (www.americorps.org/vista)

Community Software Lab
978-934-4350
www.communitysoftwarelab.org

Nathan Wiger | 15 Mar 19:23
Picon

FormBuilder 3.02 for CPAN

Attached is version 3.02 of FormBuilder that I intend to
put on CPAN.

Please take a look as it's the last release I intend to do
for a few months. In particular, read the Changes file for
a ton of new features.

Thanks,
Nate
www.formbuilder.org

Nathan Wiger | 15 Mar 19:24
Picon

Re: FormBuilder 3.02 for CPAN

The file might help...

Nathan Wiger wrote:
> Attached is version 3.02 of FormBuilder that I intend to
> put on CPAN.
> 
> Please take a look as it's the last release I intend to do
> for a few months. In particular, read the Changes file for
> a ton of new features.
> 
> Thanks,
> Nate
> www.formbuilder.org

Attachment (CGI-FormBuilder-3.02.tar.gz): application/x-gunzip, 104 KiB
Nathan Wiger | 15 Mar 19:34
Picon

Re: Suggestion for indivdual field scripting/styling

This sounds reasonable, send me a diff -u patch against 3.02 and I will 
add it. In render(), you'll likely have to change the $self->tr calls to 
instead retrieve the %attr and then change it. Check out the $self->td 
calls.

-Nate

Liu, Aaron wrote:
> Hi,
>  
>     Despite Nathan's repeated advices on not to use the 
> built-in rendering when one needs flexibility in various parts of the 
> document, I have found the built-in rendering quite sufficient for my 
> usage, with one exception: I need to be able to address individual 
> fields's containing row (<tr>) by id. With individual id assigned to the 
> table rows I can easily show and hide fields by javascript at run-time. 
> I can also highlight fields I need by applying style to individual 
> fields I needed. So far I have hacked the code (for version 2) to 
> include ths id so an input field named "password" would be enclosed 
> within a <tr id="tr_password" ... >. Do you think this feature can be 
> included in version 3 or am I just too lazy and should switch to 
> templates instead? (Or it was already in version 3 and I missed it?) Any 
> comments are welcome.
>  
> Aaron
>  

Peter Eichman | 15 Mar 21:02
Picon
Picon

problem with JS validation/requirement (Re: FormBuilder 3.02 for CPAN)

Something I just noticed with this version is that validated but not 
required fields are erroniously triggering the Javascript validation 
routines, and popping up an "invalid fields" alert.

Here is a minimal script that demonstrates this problem:

#!/usr/bin/perl -w
use strict;

# pops up an "alert" dialog even if
# the email field is blank

use CGI;
use CGI::Carp qw(fatalsToBrowser);
use CGI::FormBuilder;

my $q = CGI->new;
my $form = CGI::FormBuilder->new(
     fields => [qw(email)],
     params => $q,
);
$form->field(name => 'email', required => 0, validate => 'EMAIL');

unless ($form->submitted && $form->validate) {
     print $q->header;
     print $form->render;
} else {
     print $q->header('text/plain');
     print "Success!"
}

Related to this, I've also been wondering if it would be possible to 
separate the enabling of javascript (client-side) validation from the 
other javascript used to drive things like 'other' or 'growable' fields? 
This is not urgent, and is something I could easily look into creating a 
patch for; I thought I'd just float the idea to the list and see what 
other people felt about it.

-Peter

Nathan Wiger wrote:
> Attached is version 3.02 of FormBuilder that I intend to
> put on CPAN.
> 
> Please take a look as it's the last release I intend to do
> for a few months. In particular, read the Changes file for
> a ton of new features.
> 
> Thanks,
> Nate
> www.formbuilder.org

Nathan Wiger | 16 Mar 00:00
Picon

Re: problem with JS validation/requirement (Re: FormBuilder 3.02 for CPAN)

 > Something I just noticed with this version is that validated but not
 > required fields are erroniously triggering the Javascript validation
 > routines, and popping up an "invalid fields" alert.

Thanks Peter, I'll check that out. At first glance it appears to be 
per-browser (some like the new JS code and others don't).

Anybody on the list a JavaScript expert??

> Related to this, I've also been wondering if it would be possible to 
> separate the enabling of javascript (client-side) validation from the 
> other javascript used to drive things like 'other' or 'growable' fields? 
> This is not urgent, and is something I could easily look into creating a 
> patch for; I thought I'd just float the idea to the list and see what 
> other people felt about it.

Sounds reasonable to me.

-Nate

Liu, Aaron | 16 Mar 04:02

Selection list rendering for static mode

Hi,
 
    I think this has been fixed in version 2 previously but appears again in version 3. For selection list in static mode, I think most people will want the display value shown rather than the actual value submitted. For example,
 
<select name="word">
<option value="A">Apple
<option value="B">Boy
</select>
 
    in this case I think Apple/Boy should be shown instead of A/B. Any comments?
 
    One more difference I noticed between version 2 and 3 is that required field are rendered bold in version 3 in static mode but not so in version 2 (not that a big deal but just interesting: we use bold type to indicate required field, but in static mode it is not exactly a required field anymore.)
 
Daitau Aaron
 
ps you can tell I really am clinging to the built-in rendering instead of any external engine.
Liu, Aaron | 16 Mar 04:21

Re: Suggestion for indivdual field scripting/styling

Here is the diff, I hope this will not break anything (I just inlined
the call to tr() and added parameter to it.)

===================================================================
--- FormBuilder_orig.pm Mon Mar 14 19:32:14 2005
+++ FormBuilder.pm      Wed Mar 16 03:16:58 2005
@@ -1120,7 +1120,6 @@

         # Get table stuff and reused calls
         my $table = $self->table;
-        my $tr    = $self->tr;
         my $td    = $self->td;
         $html .= $table . "\n";     # want newline regardless

@@ -1132,7 +1131,7 @@
         for my $field (@unhidden) {
             debug 2, "render: attacking normal field '$field'";
             if ($table) {
-                $html .= $tr . $td . $font;
+                $html .= $self->tr({id=>"tr_$field"}) . $td . $font; #
generate id for table row
                 if ($field->invalid) {
                     $html .= $self->{messages}->form_invalid_opentag;
                 } elsif ($field->required) {
===================================================================

> -----Original Message-----
> From: Nathan Wiger [mailto:nate <at> sun.com] 
> Sent: Wednesday, March 16, 2005 02:35
> To: Liu, Aaron
> Cc: fbusers <at> formbuilder.org
> Subject: Re: Suggestion for indivdual field 
> 
> This sounds reasonable, send me a diff -u patch against 3.02 
> and I will 
> add it. In render(), you'll likely have to change the 
> $self->tr calls to 
> instead retrieve the %attr and then change it. Check out the 
> $self->td 
> calls.
> 
> -Nate
> 
> 
> Liu, Aaron wrote:
> > Hi,
> >  
> >     Despite Nathan's repeated advices on not to use the 
> > built-in rendering when one needs flexibility in various 
> parts of the 
> > document, I have found the built-in rendering quite 
> sufficient for my 
> > usage, with one exception: I need to be able to address individual 
> > fields's containing row (<tr>) by id. With individual id 
> assigned to the 
> > table rows I can easily show and hide fields by javascript 
> at run-time. 
> > I can also highlight fields I need by applying style to individual 
> > fields I needed. So far I have hacked the code (for version 2) to 
> > include ths id so an input field named "password" would be enclosed 
> > within a <tr id="tr_password" ... >. Do you think this 
> feature can be 
> > included in version 3 or am I just too lazy and should switch to 
> > templates instead? (Or it was already in version 3 and I 
> missed it?) Any 
> > comments are welcome.
> >  
> > Aaron
> >  
> 
> 
> 


Gmane