Nate Wiger | 1 Sep 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

Rod McChesney | 20 Sep 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 @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, @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)

Rod McChesney | 20 Sep 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
>

David Baird | 20 Sep 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 @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.


Gmane