A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
Part of a small web app we are developing allows users to build their own custom forms. They select "textbox" or "checkbox list", etc. The actual form builder tool is coming along. The architecture question we are struggling with is how to manage changes to the form.
For example, if the user builds a contact form and makes changes after receiving submissions to the form, how is this handled? Perhaps they initially had an "Address" field and then removed it. Does a version of the form need to be saved with each submission?
I should mention that the form has options set fees (perhaps you're selling t-shirts) for some items (the application supports credit card transactions). So, what if the person building the site initially charges $10 for the t-shirts but then changes it to $12. Or, changes the label from "t-shirts" to "apples". The flexibility is there.
Would greatly appreciate your guidance.
Tuesday, October 23, 2007
It is difficult to answer without knowing more about how you have implemented this. However, I have also done this kind of thing in the past quite successfully.
You will want to keep track of changes to your forms, but don't store the form with the data. Just store a pointer to the version of the form used. Or, better still, if you keep the submission date for the data, you can deduce which version of the form was in place at the time.
This assumes you keep track of each version of the form, which makes sense anyway, as you can see later who made what changes.
It really depends on if old submissions need to use the new form format or continue under the old form for their life. This is something only you can answer.
We have this issue in one of the applications I work on, where submissions go through a complex workflow and may exist for several months. During that time, if changes are made to the form, should submissions that are already halfway through the process automatically switch to the new form?
We actually support both methods, but it is a huge pain because it requires a lot of testing. It is much easier to just force the submission to continue using the version of the form it was submitted under.
Wednesday, October 24, 2007
In our application, once data has been submitted to a particular form we only allow text changes, no changes to field types or any additional or removal of fields.
We do offer an option to copy the current form into a new version of the form and they can add and remove fields with the new version. We also have a start date and end date on each version which can be editted so they can pick a future date to retire the old form and start using the new one.
When data is brought up it is displayed using the version of the form that it was attached to when it was submitted. We have had some requests to build a mapping tool to allow customers to map data from one version of a form to another version. In one case, they asked for a mapping tool that would bring data from a previously submitted form to pre-populate fields on a new form so their returning users could see what they entered on last year's form. We created a special field type for that and it worked out quite well.
Wednesday, October 24, 2007
went through this years ago with reports that the user could customise. So we had a standard report, but if we added/removed fields then it could break the customers custom forms.
Basically, I don't know enough about how robust your back end is, but every item on the form should have an internal name as well as a display label (which can be in multiple languages). User can then rename the display label, move the items around on the form & have unrestricted ability to mess with non-field cosmetics (like changing colour).
The only issue you then have to deal with is new or removed items. If the result of the form is say an XML formatted list then additional items should not be a concern; so user can have the new field 'language' on the report if it is found in the form or dropped or set to blank if the user has either not filled the field or it is not present on the earlier form version.
For dropped fields, again the back end should be robust. So if the user goes and kills the 'Address' field & then can't ship any products because they don't have shipping addresses.. too bad for them ;-). Though my template system allowed fields to have properties like 'mandatory' and 'unique' (i.e. you can have only one name field on the form).
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz