On 05 November 2001, Quinn Dunkan said:
> And it's important to have a clear idea of what "UI level" is and what "the
> other level" is.  If you've got that from the beginning, things tend to
> decompose nicely, but if you've got a sticky mess it can hard to see how to
> untangle it.

Absolutely!  But this is the sort of thing that comes naturally with
enough programming experience, or doesn't come at all.  You can't
document intuition.

> Maybe when I'm done with this and have some free (hah) time, I'll write up a
> doc and example code so other people won't fall into the trap I fell in.
> There should also possibly be a standard library of UI code...

Take a look at the quixote.form package.  It's currently undocumented,
but it's *very* useful.  You can use the widget library (in
quixote.form.widget) on its own or as part of Form objects; your call.

> Sometimes I feel like I'm reinventing Zope, but at
> least it's a Zope I understand :)

Exactly!  However, Quixote is much more strongly tied to Python than
Zope is.  And I think I can safely promise you that angle brackets will
never feature prominently in Quixote programming.  Oh, and you'll never
be able to define a web application over the web with Quixote.  That may
be useful for some people, but we found it to be an enormous pain in the
neck.  Nor will we ever use environmental acquisition for anything --
neat idea in theory, confusing and unusable in practice.  Nor will we
hide your precious source code from you in an opaque database.  Etc,
etc.

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