I keep having these flashbacks.

On Tue, 4 Sep 2001, Greg Ward wrote:

>  > How do you process and validate user input in your project?
>  
>  Two words: typed widgets.
>  
>  Philosophy: the UI should constrain the user as much as it can to make
>  sure they enter the right stuff.  The code that does that constraining
>  should be as close to the user as possible, in order to make error
>  reports as useful to the user as possible.  Since our application is a
>  web application, we have classes corresponding to all the major
>  "widgets" you can have in an HTML form.  We subclass those for
>  type-related constraints, eg. a string input box that requires integers.
>  Some widgets are inherently value-constrained -- eg. radio buttons and
>  select lists -- so our widget classes let you specify a constraint.
>  Others are inherently unconstrained (text areas, string entry, or string
>  entry that only accepts integers), and our widget classes leave them
>  as-is.

Does this mean you have "type" information stored in two separate
places? IOW, you have your DB integrity checks, and also the widget types
hardcoded or kept in a central repository? How do you uniformly keep the
types consistent and working?

>  I imagine you could cook up a similar toolkit for GUI development in
>  Python; the ideas from the Quixote Form Library are sound, and you are

I have a toolkit I work on. The entries are quite hard to get right, but
I'm progressing. However, I would like to in runtime find out what masks
or validations I should apply to the entry, and AFAICT these are tied
directly to the general "type" of the domain class attribute. 

A raise Exception can come a long way, anyway - you can catch it really
close to the user if you want closeby error handling.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL