Question

Designing and processing a form where the user can add an arbitrary number of new input fields is very tedious without using JavaScript.

Currently I am doing the following: using two different submit buttons in a form, one for adding a new input field and one for submitting the form which results into a database request.

• the used method is POST

  for adding new input fields I would like to use GET but since two methods in one form is not possible I have to do it in the POST request.

• making this for one type of input field is rather easy, but when you need to do this for sub-forms (some groups of input fields in the same form), this becomes not only tedious, but also error-prone!

I am not satisfied, is there a more intelligent way to realize this without starting to write a lot of processing code and doing redirection or at least ease the implementation to reduce the error risk!

Also, maybe there is a solution provided by Java to solve this generically elegant, since I am using Java Servlets.

With JavaScript turned on I would offer a separate solution, I am only concerned with the fall back solution, this is not the normal case.

Answer 1

See, working without JavaScript severely restrict your abilities: you have to rely upon the standard HTTP request/response cycle. In other words, you have to rebuild a new page (adding some input field) and send this new page each time – there’s no workarounds.

Here’s how I would implement it:

<form action="/path/to/action" method="post">
  <input name="param_a" />
  <input name="param_b" />
  <button type="submit" name="next_input" value="param_c">Add a field</button>
  <button type="submit" name="submit">Submit your form</button>
</form>

… then within the server-side code I’d just check whether next_input param is sent or not. If sent, its value will be used to get the control which is to be added – and give the corresponding value (param_d, for example) to the next next_input.

UPDATE: but I just can’t help wondering is this really necessary. Usually we design for ‘No JS’ cases when these pages are typical landing pages (scanned by search robots). Thinking about some users that will go to your page without JS enabled, yet willing to use it with all pretty things enabled… well, it’s not very cost-effective, to say the least. )