headers
Hasanuddin Tamir | 10 May 2006 09:11
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)

Permalink | Reply | 0 comments |
headers
Michael Collinson | 9 May 2006 08:54

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)

Permalink | Reply | 0 comments |
headers
Travis Spencer | 17 Apr 2006 21:10
Picon
Gravatar

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
Permalink | Reply | 2 comments |
headers
Nate Wiger | 21 Feb 2006 21:28
Picon
Gravatar

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...
Permalink | Reply | 0 comments |
headers
Will Kallander | 20 Feb 2006 01:19

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)

Permalink | Reply | 1 comment |
headers
Hugh Esco | 18 Feb 2006 21:53
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)

Permalink | Reply | 0 comments |
headers
Nate Wiger | 17 Oct 2005 17:35
Picon
Gravatar

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
>
>
Permalink | Reply | 0 comments |
headers
David Baird | 20 Sep 2005 09:52
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.
Permalink | Reply | 0 comments |
headers
Rod McChesney | 20 Sep 2005 02:16
Picon

Re: error handling

Any way it could be configurable? I personally would prefer the stack
trace, ugly as it is, but I can imagine others would not.

Rod

On 9/19/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
> 
> You are right,  <at> CARP_NOT is new to 5.8 and in fact I was not even
> aware of it. Looking at it, it appears to address this problem
> somewhat, although it requires 5.8 and also that
> CGI::FormBuilder::Util maintain an internal list of FormBuilder
> modules (making plugins awkward).
> 
> I would, however, be willing to change puke() to display a
> Carp::longmess backtrace (aka confess). But, this means lots more gook
> in error_log on failures.
> 
> Thoughts?
> 
> -Nate
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rod McChesney | 20 Sep 2005 03:21
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
>
Permalink | Reply | 0 comments |
headers
Nate Wiger | 1 Sep 2005 01:19
Picon

Re: Multiple Nest Loops

Todd Charron wrote:
> Ok, this has got my head spinning, so perhaps someone here can help me out.
> 
> I'm looking to have rows of data pulled from a database and put in divs within 
> a form.  if there are no rows then it should display the html once with empty 
> fields.  Each row has a drop down list populated and looped from the database 
> as well.  Once the data has been looped through, I'd like there to be one 
> loop through with no data (blank fields).

First, I would probably design this differently. I would recommend a 
screen listing existing entries, each with an "Edit" link/button, and 
then a separate add/edit form:

    Campaign           Emails              [New]
    Some value         a <at> b.com, b <at> c.com    [Edit]
    Some other value   a <at> b.com, b <at> c.com    [Edit]

The "New" button would take you to a blank form, and the "Edit" button 
would take you to the same form, just with values filled in (just pass 
the values into FormBuilder via the "values" option).

-Nate
Permalink | Reply | 0 comments |

Gmane