Hi guys,
For my $0.02, I'd just like to say that I prefer the class definition
idea. It is visually cleaner to me and we all know that code is read
more than it is written. :-)
I also agree with Ian's interpretation of "what it means" to create a
form instance. The instance in this case is just a string with (x)html
tags in it. The class is what creates that string.
This is all probably more a matter of taste, but everything else in TG,
SO and CPy is class-based, and it seems a bit inconsistent to me to have
forms work as a list-based system.
Anyway, like I said, this is my $0.02.
Other than that syntactic issue, I really like the way you are going
with this, Kevin. TG is a beautiful piece of code and just keeps
getting better! :-) Thanks for making my life easier! :-)
Krys
Ian Bicking wrote:
>
> Kevin Dangoor wrote:
>
>> On 11/1/05, Ian Bicking <[EMAIL PROTECTED]> wrote:
>>
>>> Kevin Dangoor wrote:
>>>
>>>> You can instantiate a form like this:
>>>> myform = TableForm(widgets=[
>>>> widgets.TextField("name"),
>>>> widgets.TextField("address"),
>>>> widgets.TextField("age", default=0,
>>>> validator=validators.Int())])
>>>
>>>
>>> Isn't that just begging to be...
>>>
>>> class myform(TableForm):
>>> name = widgets.TextField()
>>> address = widgets.TextField()
>>> age = widgets.TextField(default=0, validator=validators.Int())
>>>
>>> ?
>>
>>
>>
>> I don't think so. In this example, I'm not looking to create something
>> that creates forms (a class), I'm looking for a form itself (an
>> instance).
>
>
> I'm thinking from a syntactic point of view, not necessarily the
> classness. This is similar to FormEncode schemas.
>
> They can remain ordered, if TextField uses a counter to track when they
> were created relative to each other.
>
> OTOH, this is something that creates forms! You can't send this Python
> code to the client, you send what this code renders, in the context of a
> specific request. That is a reasonable way to distinguish classes and
> instances.
>
