[eluser]Randy Casburn[/eluser]
@Colin - @Chuckle -- OK off the deep end there a little...
So let me try a different way...
Let's say I'm building a Business Intelligence application with 12 data entry screens meant to collect a range of data from across an enterprise composed of finance, human capital, asset management, and provide an interface for imported data from other ERP systems.
While I'm not going to enumerate every form and field on every one of the 12 screens, we might imagine that we start to see Stores, and each Store has Inventory, and each Store and certain Financial Accounting to be done, and each Store has Human Resources to be paid, and maybe each Store is owned as a capital Asset. Now since each Store is in a Region each Region roles up the reporting of all the Stores in a Reqion and all the Regions get rolled up Nationally. All the data in the displayed on a central form screen where it can be sanitized before it is displayed to the Board of Directors.
If you think through this, you should come to the conclusion that a "financial form field" validation for a Store Accounting Page should work exactly the same way as a "financial form field" validation for a Human Resource payment calculation. Otherwise, you're duplicating your effort and you're going to create a separate validations for each of the 12 pages.
I hope this is clearer and less jargon like.
Randy
p.s. I have another question though. Where does all this "stuff" come from? Where does the definition of all this come from? Every form field for every form in every application you "design and make usable" "should" come from a data model (damn -- there I go again) that has been thought about in advance. The data model should be created from your form design mock up. Once you've eliminated all the duplication in your data model, you've removed all the duplication in your validation model! But hey...just sayin'
