On Tuesday, September 23, 2003, at 02:54 PM, Matt Feifarek wrote:
>> 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
> 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...
> 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)