[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