Yes, we do almost exactly this same thing using FFK. A single set of mutable
form definitions (which are really just placeholders for the wildly different
forms that might be created during awake) are used to modify db data. Well,
like you said.
It's been a long time since I've looked at the core of this code, I know we had
to make a few changes to how mutable forms work. I'm attaching our copy of
FFK/Form.py (which is from 0.3 I believe), I don't have time right now to diff
and explain, but maybe I will later if there are questions? Largest thing I
remember is throwing out the dynamic serial formID, and fixing some missing
stuff with removeField/replaceField.
Anyways. Last I talked to Ian about this, Mutable forms really hadn't been
tested very much at all. We now use them all the time, particularily in this
app, but I never communicated our changes (nothing really structural) to Ian.
I've been meaning to look at upgrading to FFK 0.4, maybe Ian can speak to
how/if mutable forms have changed in this rewrite?
If you've got any questions, let me know.
Quoting Aaron Held <aaron@...>:
> Has anyone tried to create fully dynamic form definitions using FFK?
> I am thinking of an app that would dynamically generate an HTML
> interface to a given table.
> Assuming that the table metadata and business rules do not change it
> should be relatively easy to create a form using the mutable
> formdefinition and validators.
> So if you want to track birthdays the SQL table could have a date, name
> and age field.
> The FFK would pick out a date and two text fields, One of the text would
> have a validator to specify an integer >= 0.
> Currently mutable form uses a module variable to store a copy of the
> form def once it is created. I would rather create it on the fly each
> (I know that there are all sorts of consistancy issues and the form def
> cannot change in the middle of a session)
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> Webware-discuss mailing list