[Catalyst] Debugging help needed

Jesse Sheidlower jester at panix.com
Sun Mar 29 16:57:49 BST 2009


On Sun, Mar 29, 2009 at 08:15:18AM -0700, J. Shirley wrote:
> On Sun, Mar 29, 2009 at 4:52 AM, Jesse Sheidlower <jester at panix.com> wrote:
> 
> >
> > I'm having a problem with an app that is totally mystifying
> > me, and several attempts to put it aside and look at it the
> > next day have failed to help me solve it. I'm sure it's
> > something totally obvious, but nothing springs to mind, so I'd
> > welcome any suggestions.
> >
> > I have a project where in one place I hard-coded some values
> > for a select list, going into a database row; now I'm moving
> > these into a table, and storing the id to this in the original
> > table. I have done similar things in other projects
> > before. This project is flexible, using a base controller and
> > so forth, so I figured all I needed to do was create a new
> > class or two and some templates, and all would work. Yet it's
> > failing, even though exactly parallel examples in the same app
> > are working fine.
> >
> > The basic problem is that when I retrieve my records, things
> > look like they're working--DBIC_TRACE shows that my query is
> > being fired; the pager that's associated with the resultset
> > shows the correct values; etc. But the actual looping over
> > the results doesn't show anything.
> >
> > In my base controller, the relevant part is this:
> >
> >  $c->stash->{record} = $c->stash->{model}->search(undef,
> > $search_conditions);
> >  $c->stash->{pager} = $c->stash->{record}->pager;
> >
> > ($search_conditions is a hashref for the page and row
> > information for the pager; the model stuff is previously set
> > in an earlier part of the chain).
> >
> > Then, in my TT template, I have (the comments with "####" are
> > things added for this post, they're not in the original):
> >
> > ---
> > [% SET tunings = record %]  #### dumping "tunings" here shows it's a DBIC
> > object
> >
> > <p><span class="lead">
> >    [% IF pager.total_entries == 1  %]
> >        1 record
> >    [% ELSE %]
> >        [% pager.total_entries %] records
> >    [% END %]
> > found; displaying [% pager.first %] &ndash; [% pager.last %]</span></p>
> >
> > #### this displays "7 records found; displaying 1 - 7", so
> > #### clearly the pager has been correctly set up, and it comes from
> > #### "record". Furthermore, if I replace "pager" with "record.pager"
> > #### things still work, so "record" seems to have the correct thing
> > #### even in the template
> >
> > <table>
> >
> > [% rowcolor = "lightrow" %]
> >
> > [% WHILE (tuning = tunings.next) %]
> >
> > #### I have the same thing in another virtually identical
> > #### template; it works there. Also, replacing "tunings" with
> > #### "record" fails in the same way, and changing "tuning"
> > #### to "fqqx" or something else also fails
> >
> >  <tr class="[% rowcolor %]">
> >    <td><a href="[% base _ 'tuning/view/' _ tuning.id %]">[% tuning
> > %]</a></td>
> >  </tr>
> >
> > [% SET rowcolor = (rowcolor == "lightrow" ? "darkrow" : "lightrow") %]
> > [% END # while %]
> >
> > </table>
> >
> > #### the result is empty <table>    </table>
> > ---
> >
> > Similarly, in the other place where I use this, where I'm
> > generating the select list, it fails in the same way. In
> > that controller I have:
> >
> >  $c->stash->{performers} = $c->model('GuitarDB::Performer')->search();
> >  $c->stash->{tunings} = $c->model('GuitarDB::Tuning')->search();
> >
> > And in the template (with some display stuff not shown):
> >
> >  <select name="performer_id" id="performer">
> >    <option value="" selected="selected">(No performer)</option>
> >    [% WHILE ( performer = performers.next ) %]
> >       <option value="[% performer.id %]">[% performer %]</option>
> >    [% END %]
> >  </select>
> >
> >  <select name="tuning_id" id="tuning">
> >    <option value="">(No tuning)</option>
> >    [% WHILE ( tuning = tunings.next ) %]
> >        <option value="[% tuning.id %]">[% tuning %]</option>
> >    [% END %]
> >  </select>
> >
> > The first one works, the second doesn't. DBIC_TRACE shows that
> > both queries (performer and tuning) are being fired, and
> > executing them each manually against the database shows that
> > the expected results are being returned.
> >
> > Can someone kick me, and tell me the obvious typo, or use of a
> > reserved word, or whatever, that I'm missing?
> >
> > Thanks.
> >
> > Jesse Sheidlower
> >
> > _______________________________________________
> > List: Catalyst at lists.scsys.co.uk
> > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> > Searchable archive:
> > http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> > Dev site: http://dev.catalyst.perl.org/
> >
> 
> 
> Do you have a string overload on [% tuning %] (that perhaps is returning an
> empty string)?

Yes.

Thank you.

mst gave me the same suggestion in a private chat; I was about
to post here to show this.

I solved the problem in two ways: first, by adding a "bool"
option to the overload; and second, by realizing that I didn't
need the NULL result in this table (it was an artifact of my
normalization routine, it wasn't actually referenced by
anything), and could just delete that row from the tuning
table.

I would never have guessed this on my own.

I'll be patching the DBIC docs to show this in the
stringification example in the Cookbook.

Thanks to mst and jshirley.

Jesse



More information about the Catalyst mailing list