--- Bill Moseley wrote:
On Wed, Jul 18, 2007 at 07:49:50AM -0700, John
Napiorkowski wrote:
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@hank.org
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.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.
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@hank.org
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@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/
