5

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.

Community
  • 1
  • 1
Mahoni
  • 7,088
  • 17
  • 58
  • 115
  • 2
    Why do you want to communicate with the server in order to add a new form field when it could just be done on the client? Also, why is this tagged `Java`? – Jivings Jun 04 '12 at 19:55
  • 1
    I agree: going round-trip to the server to add a field is a terrible user experience. There's no reason NOT to use JavaScript on the client to perform this task. – Diodeus - James MacFarlane Jun 04 '12 at 20:02
  • 1
    @Diodeus What if JavaScript is not available? – Mahoni Jun 04 '12 at 20:05
  • @Jivings It's tagged with Java, because this is the server processing language I am using (meta-question data ;) – Mahoni Jun 04 '12 at 20:06
  • @Mahoni You can rely on JavaScript to be available these days. There aren't many sites you can go on which don't require it. – Jivings Jun 04 '12 at 20:08
  • 2
    You should use JavaScript for this. – Tom Jun 04 '12 at 20:10
  • 2
    These days the user would have to DELIBERATELY turn JavaScript off, and they'd be aware of the consequences. Sure, you could fall beck to the crappy round-trip version, but that should not be the PRIMARY experience. – Diodeus - James MacFarlane Jun 04 '12 at 20:13
  • Have you seen http://stackoverflow.com/questions/597596/how-do-you-overcome-the-html-form-nesting-limitation? It might help you, if you haven't seen it already. – apsillers Jun 04 '12 at 20:17
  • 1
    @Diodeus Of course this should not be the primary experience, with JavaScript I would ease the form filling, but I need an easy fall back implementation. – Mahoni Jun 04 '12 at 21:04
  • 1
    I know it's important to offer fallbacks whenever it's feasible, but here it really might not be worth the effort. Consider how much time you're dropping into this and whether it'd be more worthwhile to simply ask users without Javascript (far less than even 1%, I'd wager) to enable it. – Matchu Jul 08 '12 at 19:44
  • I agree, JS should be a requirement, since it's a webapp I am building. That's totally legal then – Mahoni Jul 09 '12 at 00:39

1 Answers1

2

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. )

raina77ow
  • 103,633
  • 15
  • 192
  • 229