Juan, thanks for taking the time to reply. Perhaps there should be no need for the custom get_related_rows call > (and doing in the template should be, in fact, breaking MVC > principles, IMHO). If your DBIC Classes representing TableA and > TableB are properly related (master-detail, in this case, for what > shows from the example, something like: TableA has_many TableB) with > the method, say, gimme_b, something like the following should work: >
There were a couple of reasons why I was using [% rows_b = row_a.get_rows_b() %] rather than doing the query (and stashing the results) in the controller: - this operation will probably happen in several places in the web pages ( i.e. there could be several different instances of row_a) and it would be a pain to have to do each of these queries and store them as separate stash variables beforehand (the duplication leads to typos, etc) - I'm trying to be modular with the way I'm writing my templates so I can have discrete templates for each type of component (i.e. table row). I'm using something like: [% PROCESS table_a/brief_summary.tt2 row = row_a %] I guess I could change this to: [% PROCESS table_a/brief_summary.tt2 row = row_a related_rows_b = rows_b_related_to_row_a %] But again, I'll then need to maintain the interface of "brief_summary" which again leaves me open to typos, etc. If I keep the select inside "table_a/brief_summary.tt2" then I only need to pass the entity that is being displayed and let the component worry about getting the information it needs to display it. I'm happy to be told there is a more sensible way of doing this, but this seems to make sense to me. Having said all that, I've just gone back through the mailing list (with less caffeine and more sleep) and there are a couple of obvious threads that I should've seen before writing my original email ( http://www.mail-archive.com/catalyst@lists.scsys.co.uk/msg01827.html). Apologies for the false alarm. Ian On Tue, Mar 4, 2008 at 9:13 PM, Juan Miguel Paredes <[EMAIL PROTECTED]> wrote: > On Wed, Mar 5, 2008 at 3:05 PM, Ian Sillitoe <[EMAIL PROTECTED]> wrote: > > > > Controller/TableA.pm: > > $c->{stash}->{row_a} = $c->model('MyDBIC::TableA')->find('id'); > > $c->{stash}->{template} = 'view_a.tt2'; > > $c->forward('Catalyst::View::TT'); > > > > /root/src/view_a.tt2: > > [% rows_b = row_a.get_related_rows( optional => param ) %] > > [% FOREACH row_b = rows_b %] > > [% DisplayRow(row_b) %] > > [% END %] > > > > Perhaps there should be no need for the custom get_related_rows call > (and doing in the template should be, in fact, breaking MVC > principles, IMHO). If your DBIC Classes representing TableA and > TableB are properly related (master-detail, in this case, for what > shows from the example, something like: TableA has_many TableB) with > the method, say, gimme_b, something like the following should work: > > /root/src/view_a.tt2: > [% rows_b = row_a.gimme_b %] > [% FOREACH row_b = rows_b %] > [% DisplayRow(row_b) %] > [% END %] > > If, for some odd reason, the DBIC Relationships (a definite _must see_ > on the docs) are not enough for your needs, you could put all your > related rows from TableB on the stash (calling the custom model method > from your controller), so you don't make direct calls from your > template to your models. > > Anyway, that's just an opinion. HTH. > > _______________________________________________ > List: Catalyst@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/ >
_______________________________________________ List: Catalyst@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/