[Catalyst] Model/Controller logic separation - best practices?

Ian Sillitoe catalyst at sillit.com
Wed Mar 5 11:43:11 GMT 2008


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 =3D
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 =3D row_a
%]

I guess I could change this to:

[% PROCESS table_a/brief_summary.tt2
         row =3D row_a
         related_rows_b =3D 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 <juan.paredes at gmail.com>
wrote:

> On Wed, Mar 5, 2008 at 3:05 PM, Ian Sillitoe <catalyst at sillit.com> wrote:
> >
> > Controller/TableA.pm:
> > $c->{stash}->{row_a} =3D $c->model('MyDBIC::TableA')->find('id');
> > $c->{stash}->{template} =3D 'view_a.tt2';
> > $c->forward('Catalyst::View::TT');
> >
> > /root/src/view_a.tt2:
> > [% rows_b =3D row_a.get_related_rows( optional =3D> param ) %]
> > [% FOREACH row_b =3D 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 =3D row_a.gimme_b %]
> [% FOREACH row_b =3D 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 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20080305/49e64=
995/attachment.htm


More information about the Catalyst mailing list