Mark Hedges | 31 May 02:00 2006

Re: Announce: FormBuilder 3.0301 released

On Sat, 20 May 2006, Nate Wiger wrote:
> 
> CGI::FormBuilder 3.0301 has been released and posted to CPAN and
> formbuilder.org.
> 
> 3.0301 is a bugfix release to repair these main items:
> 
>    - optgroups bugfix for complex arrays
>    - removal of HTML::Entities support due to utf8 issues
>    - new es_ES Messages module with better translations
>    - a patch from Mark Hedges to enable plugin modules for mailresults()
> 
> The rest of the features remain the same as 3.03.

Hip hip hurrah!

Maybe it hasn't gone through CPAN yet because of the open bug.

http://rt.cpan.org/Public/Bug/Display.html?id=16193

At least, I can't install it yet:

    cpan> install CGI::FormBuilder
    CPAN: Storable loaded ok
    Going to read /root/.cpan/Metadata
      Database was generated on Mon, 15 May 2006 13:27:09 GMT
    CPAN: LWP::UserAgent loaded ok
    Fetching with LWP:
      http://cpan.binarycompass.org/authors/01mailrc.txt.gz
    Going to read /root/.cpan/sources/authors/01mailrc.txt.gz
(Continue reading)

Ernie Souhrada | 11 May 02:39 2006

date validation

'allo--

Being new to FB, I don't know if this is by design or not, but I noticed
that DATE, EUDATE, MMYY, and MMYYYY don't validate as expected (based on
the way the docs are written) if a user enters, for example, 8/1/2006
for August 2006.  If this is ok by design, I'd like to suggest
STRICTDATE and STRICTEUDATE (or something similar) as additional
validation rules that would require leading zeroes; if it isn't, then I
have a patch to fix these four rules so that they behave more like what
the docs suggest (which I can modify easily enough to provide new rules
instead of replacements to the exsting ones).

e.

Hasanuddin Tamir | 10 May 09:11 2006
Picon

Make 'required' as template variable

Hi All,

First of all, I just started using CGI::FB less than a month ago and I learnt
immediately that this module is a must in my toolbox. About two weeks
since I tried it, I found that there is the new version (3.03) and installed it
right away. Its modular and subclassable architecture makes it even more
sophisticated.  Thanks for Nathan Winger and all the contributors for this
great piece of (highly resuable) software.

Suprisingly I can't find any archive of this list, neither any information
about where the archive is (sorry for my ignorance if such archive does
exist). So I'm sorry if what following was already discussed and decided.

I had a need to access the 'required' property of a field from the template
file but I couldn't find a simple way to do it. My search took me to the file
CGI/FormBuilder/Template/HTML.pm and loaded it on vim. I then made
some changes locally so I can do this in the template file:

  <tmpl_loop fields>
  <tmpl_if required><b><tmpl_var label</b><tmpl_else>
    <tmpl_var label></tmpl_if>: <tmpl_var field>
  </tmpl_loop>

Basically, I added a template variable to access the required property,
so one can use it as above example as well as <tmpl_var required-[field]>.
The patch is included both inline and as an attachment since I'm not sure
which one is the correct way to send patches.

While doing the changes, I was thinking if there's more flexible way to
do this kind of changes without patching but didn't continue to elaborate
(Continue reading)

Michael Collinson | 9 May 08:54 2006

FormBuilder-generated code won't HTML validate

Hi,

We're validating to HTML 4.01 transitional and all our 
FormBuilder-generated forms fail because it is generating underbar 
prefixed id tags as in the example below.  Technically no big deal, 
but we can't claim standards compliance unless we can eliminate 
this.  It also causes a problem with CSS formatting of Submit 
buttons; good old IE works with input#fb_submit { ... } but not with 
input#_submit { ... } .

Am I missing something simple in my source code to put in a prefix so 
that it would generate something like id="fb_submit" instead?

If so, is it possible to generate such a prefix one time in one of 
the CGI::Application rather than having to go to each of our many 
forms? We are using CGI::Application and HTML::Template.

Regards,
Michael Collinson

Error Line 234 column 11: value of attribute "ID" invalid: "_" cannot 
start a name.

is generated from:

<input id="_submit" name="_submit" type="submit" value=" Register " />

<tmpl_var form-start>
...
Email Address: <TMPL_VAR field-email>
(Continue reading)

Travis Spencer | 17 Apr 21:10 2006
Picon

Passing data to TT2 after FB instantiation but before render

Hey All,

I am constructing FB objects more or less like this:

    my %vars = ( ... );
    my $form = CGI::FormBuilder->new(
        template => {
            type => 'TT2',
            template => $template,
            variable => 'form',
            data => \%vars,
        },
    );

Before calling render, I would like to pass some other variables to
the template.  How can I do this?  How can I access the data hash ref
that will be passed to the Template's constructor or the Template
object itself?

TIA!

--

Regards,

Travis Spencer

Nate Wiger | 21 Feb 21:28 2006
Picon

CGI::FormBuilder 3.03 beta2 release

All-

I finally had time to spin FormBuilder 3.03 beta2 today. I believe
this is CPAN-worthy. It's got alot of new features, including:

   - Subclassable field objects
   - Multilingual messages in utf8 for English, French,
     Spanish, Danish, Norwegian, and Japanese (thanks to all!)
   - Data::FormValidator support (thanks Peter!)
   - optgroup support (finally)
   - XHTML validation bugfixes
   - Internals fixes

It's available from formbuilder.org:

    http://www.formbuilder.org/download/CGI-FormBuilder-3.03_beta2.tar.gz

Please try it out and let me know how it works. I really want to get
this up there - it's been too long.

Thanks,
Nate

P.S. I have plans to put this into Subversion soon so development can
be shared better between everyone...

Will Kallander | 20 Feb 01:19 2006

Re: WELCOME to fbusers <at> formbuilder.org

I found something interesting so I thought I'd share...

When explicitly declaring a textarea, XHTML transitional validation
fails against the output of the formbuilder...

In my cgi, I create a field, like so:
$form->field(name => 'comments', type => 'textarea', cols => 65, rows => 15);

The output that is generated by formbuilder is like so:
<textarea cols="65" id="comments" name="comments" rows="15"
type="textarea"></textarea>

This fails to validate, according to http://validator.w3.org/check ,
because of the "type" attribute above.

So, I added a line to the Field.pm to delete that attribute like so:
> diff -u Field2.pm Field.pm
--- Field2.pm   Sun Feb 19 18:05:48 2006
+++ Field.pm    Sun Feb 19 18:06:35 2006
 <at>  <at>  -754,6 +754,7  <at>  <at> 
         $tag .= '</table>' if $checkbox_table;
     }
     elsif ($type eq 'textarea') {
+       delete $attr{'type'};
         my $text = join "\n",  <at> value;
         delete $attr{value};
         $tag .= htmltag('textarea', %attr) . escapehtml($text) . '</textarea>';

This fixed it to validate for me... YMMV.

(Continue reading)

Hugh Esco | 18 Feb 21:53 2006
Picon

issues with stickiness of loaded data

Hello folks. I'm building a class which uses CGI::FormBuilder for rendering its forms. I have code which
parses a text file. I need to present the form preloaded with the content parsed from the text file, ready
for further maniuplation.

$defref = {
      email_subject => "PrsRls: Testing Software",
      distribute_by => [],
      release_date => $releasedate,
      contact => $contact,
      title => $title,
      subtitle => $subtitle,
      body => $body,
      more_info => $moreinfo,
    };

    print STDERR "About to render page with test release loaded:\n",
        $title,$subtitle,"\n";
    print $form->render(header => 1, sticky => 1, values => $defref );
    print STDERR "Should have just rendered form.\n",
                $releasedate,"\n",$title,"\n",
                "\$defref is $defref.\n";
    print STDERR "In fact, \$defref says the title is: \n$defref->{tit
+le}";

following as best as I can the advice at: http://www.formbuilder.org/contrib/author.pl

In the logs I get:

Now running DistroPrsRls::setup() method.
Just ran setup() method.
(Continue reading)

Nate Wiger | 17 Oct 17:35 2005
Picon

Re: formbuilder.org feedback

Peter-

Sorry, I'll take a look at this asap. Unfortunately it's running
sendmail+majordomo and I need to replace it with qmail+ezmlm.

There is usually a good amount of useful traffic on the list, it's
just quiet right now...

-Nate

On 10/17/05, Peter Bocz <boczpeter <at> gmail.com> wrote:
> Hi
>
> I subscribed to fbusers mailing list, but only spam is coming on it so far. Should I unsubscribe from it as it
has no effective traffic or be patient? Some of the list members email address may have been misused.
>
> Peter
>
>

David Baird | 20 Sep 09:52 2005
Picon

Re: error handling

On 9/20/05, Nate Wiger <nwiger <at> gmail.com> wrote:
> > The problem is that FormBuilder::Util::puke walks up the whole stack, and reports the error at the top
level. In my case, this was the Catalyst main loop, so the error message was incomprehensible. I had to walk
step by step in the debugger to find out that MyModule.pm was faulty.
> >
> > Wouldn't it be better if FormBuilder just used Carp::croak ? Since Perl 5.8, there are even some nice
options like  <at> CARP_NOT, $Carp::CarpLevel so that  the client code can tune up the error handling behavior.
> 
> The problem has been that, in the past, croak() went one level up.
> This means that CGI::FormBuilder was always the suspect, since puke()
> lived in Util.pm

I think $Carp::CarpLevel can tweak that? 

d.

Rod McChesney | 20 Sep 03:21 2005
Picon

Re: error handling

Ah, that would be great. I usually turn on debug when I *really* can't
figure out what I've done wrong, and that's the case with the
form->values() errors I've hit.

Rod

On 9/19/05, Nate Wiger <nwiger <at> gmail.com> wrote:
> On 9/19/05, Rod McChesney <rod.mcchesney <at> gmail.com> wrote:
> > Any way it could be configurable? I personally would prefer the stack
> > trace, ugly as it is, but I can imagine others would not.
> 
> Maybe we could make it dependent on the setting of debug? That is, if
> debug is set then the full stack trace is printed. Otherwise, you get
> the short mess.
> 
> -Nate
>


Gmane