Trying to avoid faux nested tforms, etc

I’m going to try to accurately explain what I need help with. I am putting together a site that will allow people to put together their own online tests. When they create/edit an item/question to be on the test they can use the following select box to select what type of item/question it will be:

<select>
<option>[Select One]</option>
<option>Checkbox (Multiple Answers)</option>
<option>Date</option>
<option>Dropdown List (Only One Answer)</option>
<option>Email Address</option>
<option>Image</option>
<option>Numeric : Decimal Number</option>
<option>Numeric : Whole Number</option>
<option>Radiobutton (Only One Answer)</option>
<option>Text : Multiple Lines</option>
<option>Text : Single Line</option>
</select>

If the test creator selects an option such as “Checkbox (Multiple Answers)” then a new DIV appears where those possible multiple answers can be specified. Now the problem is that the way me and the back end guy see it now each possible answer has to be contained in its own form element because different actions can potentially be performed on each possible answer, actions such as Save, Cancel, Delete, etc. So, in short, we are ending up with something like:


<!--Begin Master Form-->
<form>

stuff (that doesn't pertain to this question but is present in the larger form on the page

more such stuff

<option>[Select One]</option>
<option selected>Checkbox (Multiple Answers)</option>
<option>Date</option>
<option>Dropdown List (Only One Answer)</option>
<option>Email Address</option>
<option>Image</option>
<option>Numeric : Decimal Number</option>
<option>Numeric : Whole Number</option>
<option>Radiobutton (Only One Answer)</option>
<option>Text : Multiple Lines</option>
<option>Text : Single Line</option>
</select>

more such stuff

more such stuff

  <form>stuff pertaining to possible answer #1</form>
  <form>stuff pertaining to possible answer #2</form>
  <form>stuff pertaining to possible answer #3</form>
  <form>stuff pertaining to possible answer #4</form>

<input type="submit" value="Save">

</form>
<!--End Master Form-->

But since you can’t nest forms we have been trying to do this thing where those dependent forms are outside of the master form in the DOM but use CSS to create a blank spot in which to rest in the master form and made to visually appear as though they are part of the master form. This is causing all sorts of other problems beyond what is described here and I just have to think there is a better way to do it. Yes, we might still be able to get this to work but I have the uneasy feeling that we are just piling hacks on top of hacks. Does anyone know a better approach?

Why not just use javascript to add/remove the fields required for each question? Rather than nesting forms as you have done you can just add whatever form fields dynamically then save everything when the user submits the master form.

You could achieve this with php or any other server side language as well but it would require a page reload.

Yes, the thing is that there is some back end database integration going on and each possible answer row has certain actions that can be performed on it, including but not limited to uploading images that will be associated with that question. If I get brazen enough I might paste in the nuttiness that is going on in each dependent form.

Here is just one of those items:

<tr>
<td class="index sequence">1</td>
<td colspan="9">
<form id="form1" method="post" data-ajax-success="showgridsave" data-ajax-failure="showgridfailure" data-ajax-complete="showgridsuccess" data-ajax-begin="validategridform" data-ajax="true" action="/testsetup/responseitemoption/edititem">
<table width="100%" border="1">
<tbody class="ui-sortable" style="">
<tr valign="top" style="">
<td class="itemlabel">
<input id="item_Label" class="text-box single-line valid" type="text" value="yes" name="item.Label" data-val-required="Label is required" data-val="true">
<span class="field-validation-valid" data-valmsg-replace="true" data-valmsg-for="item.Label"></span>
</td>
<td class="displayimage" style="height:40px;width:50px">
<img alt="" src="/content/media/yougotit.jpg?height=40&width=50">
</td>
<td class="displayimagecta">
<input type="image" src="/Content/img/upload.png" title="Upload" alt="Upload" name="">
<input type="image" src="/Content/img/delete.png" title="Remove" alt="Remove" name="">
</td>
<td class="isactive">
<input id="item_IsActive" class="check-box valid" type="checkbox" value="true" name="item.IsActive" data-val-required="The Active? field is required." data-val="true" checked="checked">
<input type="hidden" value="false" name="item.IsActive">
</td>
<td class="hiddenflds" style="display:none">
<input id="item_ID" class="text-box single-line valid" type="text" value="101" name="item.ID" data-val-required="The ID field is required." data-val-number="The field ID must be a number." data-val="true">
<input id="item_DateCreated" class="valid" type="hidden" value="10/18/2012 6:26:53 AM" name="item.DateCreated" data-val-required="The DateCreated field is required." data-val="true">
<input id="item_OwnerID" class="valid" type="hidden" value="27" name="item.OwnerID" data-val-required="The OwnerID field is required." data-val-number="The field OwnerID must be a number." data-val="true">
<input id="item_ParentID" class="valid" type="hidden" value="11" name="item.ParentID" data-val-required="The ParentID field is required." data-val-number="The field ParentID must be a number." data-val="true">
<input id="item_MediaPath" type="hidden" value="/content/media/yougotit.jpg" name="item.MediaPath">
</td>
<td class="rowcta">
<input type="image" src="/Content/img/save.png" title="Save" alt="Save" name="">
<input type="image" src="/Content/img/cancel.png" title="Cancel" alt="Cancel" name="">
<input type="image" src="/Content/img/delete.png" title="Delete" alt="Delete" name="">
</td>
</tr>
</tbody>
</table>
</form>
</td>
</tr>

The FORM element you see here represents an expanded view of one of the dependent forms seen in the first example above. And me showing this example brings up the additional frustrating issue that each of these dependent forms is in a table nested into a cell of the row that test item is in because you can wrap FORM tags around tables but not TR’s or TD’s. It’s a mess and I hate getting so hacky.

This is a BAD idea… scrap it, then think about functionality first… the code will come. :slight_smile:

  1. A from is a SINGLE submit action. making SUB forms ( pasted in or not) adds another submit action! That would get confusing in so many ways.
  2. Assuming you are avoiding AJAX ( which really for a project this complex you CANT) and just merely recalling the form from a DB, you could use FIELDSETS to identify each subform ( added bonus, the LEGEND TAG will help in navigation and semantics):

<form>
<fieldset><legend>MAIN FORM STUFF</legend>
stuff (that doesn't pertain to this question but is present in the larger form on the page

more such stuff

<option>[Select One]</option>
<option selected>Checkbox (Multiple Answers)</option>
<option>Date</option>
<option>Dropdown List (Only One Answer)</option>
<option>Email Address</option>
<option>Image</option>
<option>Numeric : Decimal Number</option>
<option>Numeric : Whole Number</option>
<option>Radiobutton (Only One Answer)</option>
<option>Text : Multiple Lines</option>
<option>Text : Single Line</option>
</select>

more such stuff

more such stuff
</fieldset>
  <fieldset><legend>stuff pertaining to possible answer #1</legend>.. code</fieldset>
  <fieldset><legend>stuff pertaining to possible answer #2</legend>.. code</fieldset>
  <fieldset><legend>stuff pertaining to possible answer #3</legend>.. code</fieldset>

<div><input type="submit" value="Save"></div>
</form>


BTW, it is even completely valid to put fieldsets within fieldsets! Just dont get all inceptiony; keep it semantically understandable or you WILL get a headache!

“Inceptiony” I like that. And, yes, as stated in the original post that is what I am trying to avoid. Believe me, Dresden, I agree with everything you are saying. The problem here is that I am only one person on the team trying to convince others there’s a better way. I think the complicated thing is that on each row the back end dev wants the test creator to be able to save things that only pertain to that row, such as image uploads for images that might only pertain to that test item, so they want the Save button on each row to be its own form submit. I tried to suggest using AJAX, which we are using to some degree in this project, but they seem to think this is the best way but it leaves me with all sorts of tricky front end juggling to do that goes against my grain.

If there is a save button on the master form, then why require the user to save individual rows? It seems like the back end dev is trying to over complicate the process for the user. Having one button save the current state of the form would make it much more intuitive. Unless the master save button does not save he individual question details which has the potential to really confuse the user and potentially anger them if they lose work.

Yes, I need to press this from a usability angle, which I then think will make things easier on front end and back end development.