[ZODB-Dev] Pre-announce: Oscar 0.1

Christian Robottom Reis kiko@async.com.br
Tue, 9 Oct 2001 04:09:19 -0300 (BRT)


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