Kevin Dangoor wrote:
> 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.
The converse could be argued just as effectively. This is a form:
'''<form action="foo" method="POST">
<table>...'''
SomeForm isn't a form, it is something that can build forms.
> someform = TableForm(TextField('age'))
>
> describes a particular form.
If it was just a form, then "someform" would be a string. Instead it is
something that can build forms. But in the end, I don't think OO means
anything one way or the other, it's just a question of what metaphors
you want to use. After all, you could argue that Book should be an
object, since it is just a specific Table. In fact, if you were making
a more relationally-focused ORM that would be a very probable choice.
Really these are just aesthetic choices. Given the three relations of
subclass, instance, and contained-by, how you map a problem to them is
largely intuitive.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
