[ZODB-Dev] Pre-announce: Oscar 0.1

[Greg Ward]

On 09 October 2001, Christian Robottom Reis said:
> I keep having these flashbacks.

[me, from 4 Sep 2001]
> 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.

For the record, this web widget framework is now avaiable as the Quixote
Form Library.  Download Quixote 0.4 and check out the "form/"
subdirectory (aka the 'quixote.form' package).  No docs yet.  This is a
pretty nice way of churning out lots of web UI where you're more
concerned with a consistent, intelligent interface than with fancy
graphic design.

[Christian again]
> 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?

Correct.  Type information is stored in the class docstrings for our
domain classes; Oscar^H^H^H^H^HGrouch parses those docstrings and uses
the type info it finds to check our database nightly.  This has nothing
at all to do with the user interface.

At the same time, our user interface code is full of things like this:

  class UserRegistrationForm
      def __init__ (self):
          self.add_widget("string", "user_id", ...)
          self.add_widget("string", "real_name", ...)
          self.add_widget("int", "age", ...)
          self.add_widget("single_select", "country",
                          value=list_of_all_countries, ...)

You get the idea.

Note that while there is a strong correlation between UI widget types
and fundamental data types, it's not 100%.  Eg. we do store the user ID
and real name as strings, which is the same type used to query the user.
But the country is stored as a 2-letter string (ISO 3166 code), while
the user enters it by selecting from a single-select list on a web page.

> 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. 

That sounds doable, but I can't offer you any advice.  We didn't go
quite that far in unifying our UI with our underlying domain classes,
and we haven't seen a burning need to yet.

        Greg
-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org