Import choices

This specific example is probably a too narrow case to be implemented. But maybe some kind of import functionality could be useful, e.g import binary choices from a CSV-file. In this case one would export usernames from the database or prepare it manually in Excel or similar and then import the file.

I will agree with Anders that this will most likely be implemented in the foreseeable future as an import-choices-from-file or import-choices-from-textarea feature. They are more flexible features that will be used by a broader audience.

BUT once one or both of those are implemented it would be easy to copy and paste a list of users into the file/textarea.

Textarea sound like a good idea, maybe an option to swtich between a textarea and the usual choice fields as input option on the edit page.

One idea could be to switch to a textarea altogether, and store one choice per row. If it's possible to dynamically turn that HTML to an interface similar to what we have today we could gain two things: (i) a simple swith to an "import mode" and (ii) we could get rid of "#DANGEROUS_SKIP_CHECK" (not sure if it's a big problem though) and still have a responsive interface (not needing AJAX, see e.g. http://drupal.org/node/155870).

Here is a start on the back-end. I think this looks promising.

* Choices is now a textarea instead of seperate input fields
* Maximus choices is now a texfield instead of a select since the user can add an unlimited amounts of choices directly.

This actually had more benefits than I thought from the beginning and a lot of (ugly) code was removed (#DANGEROUS_SKIP_CHECK, $form['#multistep'] , $_POST).

TODO:
* I haven't dealt with the write-ins on the edit page (see TODO in patch). Probably we could just store the information in a seperate array (?).
* No JavaScript yet, buy I'm positive here. Choices and max choices should ideally be converted to input fields resp. a select box on page load.

Fixed element names in form_set_error().

I can see the appeal but I'm not convinced this is a good idea considering that importing choices is a low priority feature and could be implemented in a less obtrusive way.

1. It seems like a step backward in UI for non-JS users - instead of protected interface they have a free-form interface that is more error-prone.

2. Is it really going to simplify the code much if we have to re-implement the basic form items in javascript rather than using Drupal's Form API?

3. It's a dangerous data-integrity combination: it makes it intuitive to re-order the choices but makes it impossible to know whether or not the choices have been re-ordered so that the votes can stay consistent. And the AHAH features in D6 seems like it will make dynamic re-ordering of choices really simple to implement if we stick to our normal input boxes.

What do you think?

1. True, but since everyone has JS these days, not such a big issue IMO.
2. I was thinking we render a "template" form item that we make available through Drupal.settings. It is sort of how we do it now, cloning an existing form item and replacing the numbers.
3. Not an issue UI wise if we assume that JS is used (which I think we should...) since the UI will look the same. It could be an issue if we want to support re-ordering of choices though, and this might be the big drawback. I can't immediately think of a good way of supporting this. But on the other hand we don't support that now either., and if we would, we probably have to introduce a 'weight' field... Hmm, we might need do elaborate more about the re-ordering thing.

The biggest advantage I see in this (now that you convinced me that the import thing is secondary) is that we have a way to provide new choices without having to resort to #DANGEROUS_SKIP_CHECK or AJAX. The new AHAH stuff I tested is cool, but the interface is not super snappy.

IMO re-ordering of choices is inevitably going to need to be added at some point, because it's a fundamental necessity for a full-featured voting application. We shouldn't mandate that choices stay in the same order that they were originally submitted, forcing users to create a new poll if they want to revise the ordering. It will require a separate database field for choice_id and/or weight, and the ability to track that with the title & vote_offset of each choice. The UI can be implemented via both AJAX/AHAH and manual form submissions.

So I guess the "universal" textarea is of the list then. Too bad, it was a nice idea me thinks.

Let's revisit this issue. We now have a "default choices" textarea for content-type settings, and we are close to having reordering support. I bet it will be pretty easy to just add an "import choices" fieldset with a textarea in it.

I've been thinking about this old issue a little bit. What if when you first create a poll you have a textarea, then when editing it uses the usual input choices? That would make it easier to create polls with a lot of choices while still allowing us to track choice ids *after* a poll has been created. Or would this be confusing to the user?

Sounds like a good trade-off limiting the import option to new polls. Shouldn't be confusing if the UI is done right.

D6 is EOL, hence this won't be fixed / attended.