Kevin Dangoor wrote: > On 10/23/05, Ian Bicking <[EMAIL PROTECTED]> wrote: > >>And then extract these into a schema. But while you might want this >>validation on a form, I'm of the opinion that it's better to be more lax >>when doing programmatic updates, especially because there might not be a >>feedback cycle to correct problems (as with a human doing updates). > > > Not just that, but a web form might look different from what's in the > database. Here's an awful example, but it makes the point: if you have > 3 text fields for entering area code, prefix and number for a phone > number. Those 3 fields come into the controller, but only one gets > stored in the database.
I think validation can be very UI-oriented, not just data/model oriented. For instance, I use TEXT columns all the time, unless there's a concrete reason not to, because it is least likely to cause problems in the future. And generally people have a tendency to restrict types and formats more than they have to. I guess it's because databases are often content repositories, and when they are they should be treated as such. But I digress. When validation is UI, putting validation into the view/template starts making more sense. I think this is a good justification of Subway's inclination to use htmlfill_schemabuilder. In a practical sense, when I'm collaborating with people at work, it's often the people who are involved with the view that are also most interested in the validation, but if it is in Python code it's largely inaccessible to them. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
