Arc v' May 06, 2003

Writing about ASP.NET, whyTHEluckySTIFF writes:

Validation controls are way too simplistic. What if I want to validate a control based on the condition of another control? On many forms, I want to ignore some fields based on the state of a checkbox. This should be easy. I've built some complex validation controls and I hope to put them up here sometime to soothe other developer's frustrations. I imagine this is a common complaint.

Ohhhhh. Yes it is. I'm sure it's a very common complaint. I'm not using ASP.NET, but a godsend in my life for Zope has been Formulator. I'm now in the habit of defining my forms on disks in Zope products (just using regular Python code - not the Formulator XML syntax), and in the last couple of days have had some tremendous experiences with it. Inspired by Zope 3's schema capabilities (which is what Formulator morphed into when it became part of Zope 3), I'm using my forms as so much more than just display data. They've become an interface definition of sorts (which is exactly how they're used in Zope 3). I rely on them to prepare data before sending it off to a database. And there's this wonderful validation thing.

And let's face it - simple form validation is better than none. We've been using Formulator for quite some time on the public side of our sites. Where we've avoided using it is in the administration screens. Normally, we keep these to ourselves and they're not terribly glamourous. But as we're turning more products over to customers, validation's become increasingly important. Now that a form definition is being used to prep data for the database, it's become exceedingly important.

But now that the simple validation is out of the way, what now? I have a situation where I have multiple date/time fields. I need to put in some rules that say "The off sale date can't be earlier than the on-sale date" or "the show date can't be earlier than the display date". It's easy to process this stuff brute force, but it would be nice to tie it in to the core validation framework. Pulling rabbits out of my ass here, I'd imagine a way to add extra validators onto Formulator - objects that contain some sort of validation code that effects multiple fields, and has a way of highlighting which fields are in error. But... Well, there are all sorts of ramifications of this that might change how the validation errors are or can be reported. I do know that I can probably make something work for my own system. Hmmm...

Yes, it's been quiet lately. I'm buried deep in a project where I'm still (as always) wrestling with the SQL/Logic/Object gap. I've decided that:

• Using APE would require a significant application rewrite, which I don't have time for in the current schedule.
• Other tools, such as Modeling, are too immature or put too many SCM burdens on me in their dependencies that, again, I don't have time in the schedule for.

Sigh.. It's always a matter of scheduling. In the meantime, I have come up with (sigh) an in-house solution that seems to be working, thus far. It primarily tries to cut down on the database access in the area that's the most mundane - inserts, updates, and deletes. And it also works to cut down on having to add new fields manually to an HTML page through form definitions (which reside on disk now) that are used to validate and prepare data that is to be sent to the RDBMS. It's nothing terribly fancy - it's a combination of some Zope 3 schema concepts with some patterns that Ape uses, in a way that doesn't require overhauling my perception of the application revision in question.

That said, I'm going to take a look at this Martin Fowler article about Domain Logic and SQL to see if it has anything extra to teach me. Which makes this post as much of a reminder of what to read when I hit the office as it is an update on what's been going on in the software architecture front.