Ability to show or hide fields in the form based on the condition of a prior selection. This might be constructed like a fieldset, where the 'default' field is the conditional, and any others are shown when the condition is true. Not just boolean conditions, also match particular values in a select field...

Most public forms need captchas now. PFG should model best practice by shipping a captcha field, probably PFGCaptchaField.

In rating-scale field questions are stored as numeric strings and are sorted afphabetically, which messes up the original order in case of more than 9 questions, i.e. 1: Strongly disagree, 10: Disagree, 11: Agree, 12: Strongly disagree, 2: Disagree, 3: Neither agree nor disagree, 4: Agree. A simple solution would be to store a double-digit equivalent for the first 9 numbers: 01,02,...09,10,11

Duplicate the alert from the control panel if the mailhost hasn't been configured for the site yet. Currently there's no indication of an unconfigured mailhost until you submit the form and get an exception.

We need to make the add menu show the correct items if Form Folder is the default item in its containing folder.

Currently you get the add item menu for the containing folder, and I'm not sure there's a way to add a field without temporarily making the form folder non-default... Not sure the best way to fix this off-hand.

I have made a hack in PloneFormGen that allows you to have a central repository of fieldsets, and then you just add an alias for a desired fieldset in the form you are making locally. The alias is an object that behaves as a fieldset but in fact takes its fields from the central repository. In this way you can change something in the repos and the change affects all aliases.

jorgen@webworks.se

In the following check in I had to work around an issue with failing zope.testbrowser tests: http://dev.plone.org/collective/changeset/78118/ The fix is certainly not elegant, but the implementation doesn't rely on forms in any relevant way anyhow. This could all easily work without javascript enabled, but failing that it could certainly behave better when javascript is disabled. In the end, we definitely don't want to have standalone <input> tags if we want our functional tests to continue working.