which are only slightly different). Compound fields mean you can have something like a credit card field, which is actually three fields (type, number, expiration) together with validation (e.g., that the type matches the number). There are also some more sophisticated stand-alone widgets dealing with file uploads and other stuff, though I don't know if there's anything keeping you from making the same in FormKit.
We've actually had compound fields all along; since our first release. They're slightly more complicated than a normal field, but they work pretty well. In fact, there are two examples in the Examples dir.
We've also done file uploads all along. It's a bit of a hack, but then so is fild-uploading over http anyway.
Some of the file uploading widgets I have save the file upload in case of an error, so you don't have to reupload when you correct other fields. And a couple little variations on that. I'm sure it wouldn't be that hard to add -- and indeed I worry that these little details in FFK are too hard to communicate so they wouldn't be likely to be used that often -- but that's the kind of things I've been thinking of.
I think FFK's automatic form layout makes for nice forms for most situations, with fairly minimal description. Again, this is something that could be added on separately from the core package. For more general form tempating, I think something like this would be best:
http://simon.incutio.com/archive/2003/06/17/theHolyGrail
He's not really doing templating that I can tell. Do you mean the way he handles error markup?
It's kind of a pseudo-template. If you have something like:
<input type="text" name="username">
In your template, the form library finds that tag and adds the appropriate value attribute according to your default or (when errors occurred) request value. Or if it finds a checkbox it might add a checked attribute (if appropriate). Or a selected attribute to a select box. It's not a great way to do more advanced DHTML widgets (in fact, I imagine they would be hard to do in this system), but it allows the template to be very flexible.
Templating continues to be a thorn in our side, for all of our projects, not just form-related. It's a PITA. Our basic table dump isn't very pretty, but we had hoped that people would dig in and get the granular access to the labels and tags that we tried so hard to build. We don't seem to have communicated that very well...
We're adding a divDump() coupled with some default css in the next small release. That may help.
And of course there's the general issue of repeating and compound fields -- I think they are an
I tried to read the Readme.txt in FormEncode to determine what a "repeating" field is... but I couldn't find it. Can you briefly explain? It sounds important.
Repeating fields are fields that can occur multiple times in the same form. If you try the FormEncode demo (umm... if it works right now ;) it has an example -- in that example you get a list of names (first and last?), plus phone numbers for that name (at least, I think that's the example I made...)
So you can have an arbitrary number of names, and each name can have an arbitrary number of phone numbers, all in one form with validation and doing updates on all fields simultaneously. (You can do the same thing in FFK as well) With FormEncode you can even shortcircuit validation so that you can do operations like adding a phone number entry without requiring the entire form be valid at the time. If you look at the code, it gets pretty complex, but that was my first go and I should make some changes to FormEncode to make it easier (and I can't rule out rewriting the entire form rendering/processing stuff either).
As you can imagine, this complicated form definitions somewhat, but it complicates form rendering and processing considerably, and makes arbitrary templates particularly hard, because you have to start supporting looping and various other combinations (even nested loops... ack!).
Soon, maybe after our next small release, I'd like to get a discussion going with you and some of the other people who seem interested in forms, and find a way to get some library actually /built-in/ to Webkit. It seems like a glaring omission that it's not there, and between your library and ours, I'm sure that we can find a good candidate. I'll send in a note with some ideas and questions for discussion in the next week or so.
Yes, I'd certainly be interested in that. I think we could actually go beyond just Webware as well -- there's interest in this sort of thing in Python in general, and you can do a lot of this stuff without being tied to a framework.
With FormEncode I used the component stuff I had played with earlier to provide the Webware integration. I think it worked reasonably well. That might be a way to be both framework-neutral but also tied into Webware nicely at the same time. (Though the components are tied to a class similar to Page, which I wonder might be the wrong level -- Page itself is a sort of mini-framework, and there are other possibilities that could live in Webware)
Ian
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
