[Catalyst] Making Controllers thin and Models thick

[John Napiorkowski]

--- Bill Moseley <moseley at hank.org> wrote:

> On Wed, Jul 18, 2007 at 07:49:50AM -0700, John
> Napiorkowski wrote:
> > I've come to the reluctant conclusion that for
> > anything other than trivial applications you will
> need
> > to validate in a couple of places.  Obviously the
> > database should be properly designed to enforce
> > integrity rules.  If you are using a database that
> > let's you create custom types, like Postgresql,
> you
> > can take it a bit further and actually create self
> > validating types for your columns.  I do this for
> very
> > common things like email addresses.  Postgresql is
> > nice for this since you can create custom types
> and
> > domains using Perl as your procedural language.
> 
> Yes, validation is a bit generic of a term.
> 
> For me, the database should try and enforce a valid
> state of
> the application.  An order row better reference a
> customer row.
> An order status better reference a valid value in
> the status table or
> have a valid check constraint.
> 
> Doesn't mean a bit of raw DBI can't hose the
> application, of course.
> 
> For application state changes I try and abstract
> that into a method in
> the model.  I rarely have ORM specific code in the
> controller.
> 
> I tend to not validate things like email addresses
> or phone numbers at
> the RDBMS level -- it's not critical to the state of
> the application
> typically.  That's left to an I/O layer that is my
> user input
> validation code.  That code can be used outside of
> Catalyst -- and
> as I commented before, it's not tied to the
> model/ORM either.
> 
> Application state changes are typically caused by
> user input. And user
> input is often multiple fields.  So, it makes sense
> to defined
> forms for handling a set of fields all as one unit. 
> That validation
> is also not easily defined in a static configuration
> file (or by
> constraints on the database) so it also makes sense
> the forms are
> bundled with code.
> 
> I doubt there's any best approach.  But, if the idea
> is thin
> controllers then I like using one line of code. ;)
> 
> -- 
> Bill Moseley
> moseley at hank.org

Considering that you can set actions and action
classes via the central configuration file for a
controller you could eventually get down to not
needing any code, just configuration declarations. 
Still need to write a stub for your controllers
though.

I'm going to trying using the Workflow module
(http://search.cpan.org/~jonasbn/Workflow-0.28/) on my
next project and see if that can fill a missing piece
for me conceptually.  I think it can help cover the
state issues you mentioned.  Plus it has a validation
framework as part of it.

I end up with more in the database because the
applications I'm writing will end up being used by
other systems and I can't count on the PHP people
validating their incoming stuff properly :)

--John
> 
> 
> _______________________________________________
> List: Catalyst at lists.rawmode.org
> Listinfo:
> http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive:
>
http://www.mail-archive.com/catalyst@lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/
> 



       
____________________________________________________________________________________
Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/