Edmund Lian wrote:
The kinds of attributes associated with each thing, and the kinds of thingsI'm going to chime in here, a bit.
associated with each request are looked up, and the form is built
dynamically. Mutable forms are an absolute must since there are literally
billions of forms possible, and I won't live long enough to write each one
statically!
We do this all the time with our own FormKit. It works very well. I recognize that this is somewhat off-topic, since this is really about FFK, but maybe some cross-pollination is good.
if something_is_true:
self.form.addField('middleName')
Seems like a pretty elementary idea that should be accomodated.
I'm not expert in the distinction between imperative and declarative (but I think I grok the gist) but I'll say that our design in FK was very specifically deliberate.
Looking at the "style" of Webkit/Webware, we thought that we should emulate it as much as possible... the awake-respond-sleep cycle, the method-izing of ideas like actions, writeBody, writeHeaders, etc. There always seems to be a painfully slow and specific way to do things, even if there's a shortcut... just like python ;-)
It seems to be a PITA to have to do this:
f = form()
f.addField(TextField('foo'))
f.foo.addStyle({'color':'red'})
f.foo.addValidator(SomeVal())
f.foo.addAttribute('''onclick='func();'''')
etc...
It IS a pita, but that's the beginner way to do it. It's PAINFULLY imperative. One can also lump each of those things into the constructor phase, or set up subclasses of fields with application-meaningful defaults. Our aim was to be as "standard python" as possible. Webware/Webkit is not necessarily the only use.
The approach in FFK 0.3 (and it seems in your new idea, Ian) is fundamentally different; it seems to be about writing a "recipe" that then can make a form. I think that this is a valid approach, in all the ways you look at it. It's a "form construction kit" recipe.
Now, personally, I don't like to have to learn another syntax, even one that seems quite well thought-out (as what I've read so far does). It's just harder for me to remember how to set up a form recipe than to just start typing python code. It also gives one more flexibility on how/when/where to make and muck with a form... it doesn't have to be all figured out at the top of a servlet. In our FormKit, you can stick the entire form handling bit in an isolated method, if you like; you don't HAVE to use the mixin integration.
I say to each his own. What would be nice would be to abstract both of these approaches somehow, and maybe even a step higher, so that the "recipe" could be an xml file or something.
I'd love to contribute meaningfully to this kind of effort; this week I'm very busy (DSL going out of business) but if the "gang" thinks it would be useful, I'll try and chip in during the coming weeks.
On the other hand, it seems like a higher priority to rev Ww than form stuff ;-P
Forms seem like such a basic thing, it's a testament to how bad that they suck in HTML that it's this hard to write nice clean code for them.
-- Matt
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
