On Jul 18, 2007, at 8:07 AM, Bill Moseley wrote:
I do wonder if that's not coupling the ORM and the validation too
closely. Not that it happens very often, but if you decided to change
ORMs you would would still want the same validation of input data.

I tend to have a separate layer between the controller and the model
for validation.
That makes a certain amount of sense. When it comes down to it,
there are three validation layers

1. UI
Dealing with things that are specific to user interactions. E.g. Ask
for the password twice.

2. Biz-logic
Things you've specified for you application. E.g. We need an email
address for all new accounts

3. DB
Constraints specific to the database and object model. E.g. Field
length, required fields.

By putting #2 in the ResultSet I'm assuming that the structure of the
underlying database will always be the same, and you're right, that's
not always a safe bet.

I am planning on automating #3. After going to all the trouble of
specifying the database structure in my Perl code, I'm certainly not
going to turn around and write code to check field lengths and types
by hand. Oddly I haven't seen a DBIx::Class::Validate library anywhere.
In short the CRUD controller actions using it can be as simple as:

sub update : Local {
my ( $self, $c, $id ) = @_;
if ( $c->request->method eq 'POST' ){
my $update_result = $c->model( 'DB::Table' )->build_update(
$id, $c->request->params() );
if ( $update_result->{status} eq 'OK' ){
$c->res->redirect( $c->uri_for( "table/view", $id") );
$c->stash( update_result => $update_result );
$c->stash( item => $c->model( 'DB::Table' )->find( $id ) );

I suspect you write that enough times and you will notice the common

My Create/Update controllers tend to look like this:

sub edit : Local {
my ( $self, $c, $id ) = @_;

$c->post_redirect( 'list', 'Foo was updated' )
if $c->update_from_from( $id );


Because update_from_form knows the action path and can therefore find
the associated form. It can also determine what the concept of a
posted form is in a single place. And the associated form knows what
model class to update or create a row in. And the model class knows
how to validate ids. And the form knows how to look at the model
class and determine lookup values for one-to-many and many-to-many
That's a lot of info crammed into one paragraph. Let me expand it
out here just to make sure I've got it.

First of all, what's "$id"? The object being updated? And if so,
where did it come from? I can think of a couple options, but the
fact that "edit" is "Local" makes them unlikely.

So, first update_from_form looks at the action path to determine
which form is being submitted. Then it dispatches the validation and
update task to that form. That implies you have (at least logically)
an object model for forms? Which means that forms can easily share
common validation and other objects; which is very nice. How is that
set up, and how does the form know what model it is managing?
that might be considered part of the validation and the form module
can validate that the user can access $id. But, I kind of consider
that more of a controller responsibility since an invalid $id in the
path for a given user is an invalid path (and thus maybe a 404).

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 13 of 14 | next ›
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedJul 12, '07 at 9:44p
activeJul 18, '07 at 6:48p



site design / logo © 2022 Grokbase