Consider this example:
class Book(SQLObject):
title = StringCol()
author = StringCol()
That statement doesn't reflect *a* book. That statement describes what
books are all like.
twocities = Book(title="A Tale of Two Cities", author="Charles Dikkens")
This statement describes a single book, by the well-known Dutch author
Charles Dikkens. :)
class SomeForm(TableForm):
age = TextField()
name = TextField()
city = TextField()
In standard OO terminology, that statement doesn't describe a form. It
describes a *kind* of form.
someform = TableForm(TextField('age'))
describes a particular form.
Aside from that, the mechanism required to preserve ordering seems
smelly. Python keeps class and instance attributes in dictionaries,
which are unordered. To maintain the ordering, if I understand Ian's
suggestion well enough, the form metaclass would need to initialize a
counter that each widget will increment as it's instantiated. (Or some
similar mechanism, like having each widget added to a list behind the
scenes as it's instantiated.) That's not pleasant, to me.
Of course, behind the scenes implementation details for the framework
don't always have to be the best if it results in a better API, but
I'm not completely sure that's the case.
On 11/11/05, Levi <[EMAIL PROTECTED]> wrote:
>
> Interesting points. I'll have chew on them. In my mind, forms are
> entities, just like tables are entities. Each carries it's own
> attributes (ie: form elements, template, etc.) and invariants (ie: form
> level validations).
>
>
--
Kevin Dangoor
Author of the Zesty News RSS newsreader
email: [EMAIL PROTECTED]
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com
