[Catalyst] best practices for Catalyst development

[Perrin Harkins]

On Thu, 2005-08-11 at 13:55 -0400, David Storrs wrote:
> > Let's get pragmatic again. Perrin is IMHO successfully arguing the
> > need for a clean separation between stuff-that-is-useful-in-crontabs,
> > stuff-that-draws-pictures-blasts-out-HTML-whatever and
> > stuff-that-holds-everything-together.
> 
> Could you, or Perrin, point me at his arguments?  I've seen a lot of  
> assertions, but so far I don't believe anyone in the thread-- 
> including me--has said "I do XYZ because of ABC.  Here are the pros  
> and cons that I evaluated to make this decision."

>From what you wrote below, it sounds like you understood it all just
fine.

>      [*] Ok, technically, you don't NEED to put all your  
> functionality into M, V, or C...you can have all the functionality in  
> App.pm if you want.  Or you can have completely separate modules that  
> are not in the M, V, C paradigm.  These options are outside the  
> intention of Catalyst and outside the scope of this thread.

My opinion is that Catalyst intentionally does not force you to do MVC,
and that's fine because many people need some glue code like Catalyst
but don't want to really do MVC.  There is some extra code to write for
MVC apps that may not be worth it for a short-lived or very small
application.

> My divisions:
> 
> - V
>      The View is only responsible for generating HTML output.

Sometimes it may have to rearrange some data, and sometimes it may be
PDF output or XML output, but the end goal for the view is the output.

>      TT.pm    A series of methods that do nothing but set $c->stash-> 
> {template}
> 
>      The actual View logic goes in the templates, as TT directives.
> 
>      PRO: - There is almost no code in the View, so there is almost  
> nothing to test/debug.

Hmmm, complex TT templates require a lot of testing in my experience.

There are many PROs for separating the view though.  One of them is
having the option to produce PDF without changing your model code.

> 
>      CON: - This is the opposite of the desktop MVC model, where the  
> Model is the active object.
>              Departing from standards is bad and can cause  
> confusion.  OTOH, the passive Model
>              is common in Web applications, so I think this is but a  
> venal sin at worst.

The other CON is that it limits the reuse you get from your application
logic code when you put it in the controller and tie it to specific form
inputs and URLs.  That kind of separation was part of the objective of
MVC.

> -C
>      The Controller contains all the application-specific code.

That's the bit I'm not keen on for MVC apps.

>      There should be separate,
>      completely self-contained modules which the C calls out to in  
> order to generate the values
>      that are then stashed.  Doing it this way means that those  
> generic modules are not dependent
>      on your web app and can be reused in crontabs, CLI apps, etc.  
> [Nod towards each of the multiple
>      people on the thread who has previously asserted this idea.]

That's pretty much it.  It also means you can avoid copy-and-paste
coding if you need to reuse some of that logic in another part of your
app.

>      PRO: - It is clear where code for a particular task will be.
>           - Preference:  As previously mentioned, the word  
> 'Controller' sounds active to me, so
>              it fits easily into the idea of doing most of the work.
>           - Having almost all the app's code in the C means fewer  
> points of interaction with the
>              M and the V and therefore fewer points of failure.

It means less code to write, but it also means less abstraction and poor
separation between application logic and web-specific concerns.

>      DISCUSSION: I am unsure of whether it makes
>      more sense to set the template here, to keep the two pieces of  
> information (what template, and
>      what values it is to be filled with) near each other.

I set the template in the controller.  I don't have my model classes put
things into the stash -- I make the controller ask them for data or put
the objects themselves into the stash.

- Perrin