create new tag
, view all tags

Feature Proposal: Add support for selection boxes with multiple selections


complete TWikiForms' capabilities to cover more form features of html


The only possibility to have multiple selections in a form is to use checkboxes. In general it should be possible to use

<select multiple>

as an alternative.

Note, that this will allow comma separated values for keys that use such a field type like checkboxes do.

-- MichaelDaum - 19 Aug 2005

Impact and Available Solutions


If necessary, user documentation of new features introduced by this proposal.


Example uses of features introduced by proposal.


Any comments on how the feature is implemented or could be improved


If you do this, please make sure that the many places where we create forms are updated accordingly....

-- ThomasWeigert - 19 Aug 2005

The only possibility to have multiple selections in a form is to use checkboxes

Or a list box with control click.

-- ArthurClemens - 19 Aug 2005

... inside a <select multiple> yes. But TWiki can't render <select multiple>. within the TWikiForms specs.

-- MichaelDaum - 19 Aug 2005

Perhaps you should check FormFieldsPlugin. It seems to add the capabilities you want.

-- RafaelAlvarez - 19 Aug 2005

I agree with Michael that this should be a core function, and should not require a plugin. But no-one is stepping up to implement it..... unless someone does, i will have to drop it from DakarRelease.

-- CrawfordCurrie - 28 Aug 2005

Here's a patch against Cairo release. I don't know how Dakar is different from Cairo, though.

Note: It lacks deeper considerations on how %VARIABLES should be treated. Current implementation just expand all the variables before splitting into options list. That means you cannot offer %WEB% as an option. Once the topic is saved, it is the web name and no longer %WEB%. In addition, there might be some <nop> confusion...


-- KaoruMaeda - 31 Aug 2005

Dakar is very different. A Cairo patch is not going to work for Dakar.

I'm somewhat concerned by your remark above, and the presence of %DEFAULTOPTION% in the patch code. Exactly what spec have you implemented? Also, where are the tests? They seem to be missing from the patch...?

Sorry, but I think you probably need to look again at the Dakar codebase.

-- CrawfordCurrie - 01 Sep 2005

Right. I'm not familiar with Dakar codebase. Sorry I can't contribute in better way.

-- KaoruMaeda - 02 Sep 2005

Thanks, Kaoru! Maybe your code can be refactored to be used in the dakar engine.

-- MichaelDaum - 02 Sep 2005

Yes, thank you Kaoru! This patch is a lifesaver for me and works beautifully! (also with WysiwygPlugin)

This is very desirable when forms are used to 'tag' topic content using predefined keywords. Usually more than one applies.

I cannot code, but am willing to aid anyone by testing, doccing. I hope this functionality can make it into Dakar!

-- JosMaccabiani - 04 Sep 2005

I've spent the last day or so looking into this issue (as anyone that has been hanging out in #twiki can attest) and have a few issues that need to be resolved before I can contribute my solution (which works in all cases I've tested it, but I don't know how it might interact with features I'm unaware of or don't use).

Two bits of background information: First, FormFieldsPlugin doesn't work if javascript is disabled. If we can easily solve this problem without needing javascript, I think that's a good thing. Second, FormFieldsPlugin needs work to work with Dakar.

Second, my plugin adds three features to a select field type, and you can use them in any combination.

Makes the select element a multiselect
Makes the size of a select shrink to the number of options in the select if there are fewer options than the size makes room for, with the exception that it will never shrink the select below size 1.
Allows for selects where the value of the option is not the same as the text displayed.

Of these, only the first requires any modification to Form.pm or any other part of core, though I still mention them because they might affect one of the other issues under discussion.

I've done a plug in (currently requires a change in one line of Form.pm) that can stand alone as a Plugin, or get integrated into Form.pm. However, I'd like to take the opportunity to get some feedback on the best way to approach this first.

Three issues, one of which breaks down into two more issues.

First, there's a needed change in Form.pm, unless there's some way to hook into getFieldValuesFromQuery() that I can't find. The issue is that getFieldValuesFromQuery() special-cases multiple values for the same field for checkbox form field types, in all other cases,the field only gets one of the values. It's a one-line change to make that subroutine deal with multiple values for checkbox and select field types. However, to make it only happen for multiple select fields requires that it know which fields are multiple select. Hooking into something that occurs after the form has been parsed but before getFieldValuesFromQuery() gets called would be an option, but it doesn't smell right.

The way I see it, there's several approaches to this:

  1. Make the one line change that doesn't account for the type of select.
    • Pros
      • Simple solution
    • Cons
      • SMELL: I don't know if there's ever a time when someone will have multiple values for a single field and only want one, but this would cause problems in that case.
  2. Make the one line change that does account for the type of select.
    • Pros
      • Solution almost as simple as the first one, just a more complicated regexp.
      • Since it does know when it's a multiselect, it won't cause any side-effects to single-value selects.
    • Cons
      • SMELL: Unless the extended select functionality gets moved into core, this would mean that core would have knowledge of one specific plugin.
  3. Create a hook for getFieldValuesFromQuery().
    • Pros
      • Lends itself to other plugins creating custom, complex field types.
    • Cons
      • I'm not sure I'm up to adding new hook functionality to the core, I haven't looked at what it would take.
  4. Hook into some hook that fires between the form being parsed and the parameters being read in.
    • Pros
      • Doesn't change core in any way
    • Cons
      • SMELL: I'm not sure why this smells wrong, but it does, at least to me. At the very least, it's a non-obvious solution that requires knowledge of the order of events rather than just the event you're trying to modify.

Of these, I definitely like the third solution. Enough so that even if the specific functionality I need for this gets moved into core, that is still a good feature in my opinion.

The second issue is the syntax for the changes. At first, I was looking at doing it the same way as checkbox does with checkbox+buttons, having +options for each extended select feature. I'm fine with that, but when I was looking at FormFieldsPlugin, I discovered that I could do it as 'select multi="on" which seems cleaner to me, even if it is more verbose. The +options has the advantage that it's already in use in core, so it might feel more natural to existing users of checkbox+buttons, and it is more concise. However, it's also less flexible, as the multi="on" allows for more than just on/off indication.

My existing code uses +options, but I doubt it would take much to make it work with the multi="on" type options, and shouldn't even be hard to allow for both.

The immediate use for option="value" formatting I can think of is to allow shrink=2 to mean "shrink size no smaller than 2."

Third, the lesser issue of making this a plugin, or merging to core. I don't consider this much of an issue, as except for the first issue mentioned, the code only requires one or two lines to be changed to directly replace the existing select handling in renderFieldForEdit(). I'm fine with making it a plugin until we're certain it has no side-effects, then moving it into core if there's a demand for it.

As a final note, the values option, which hasn't been mentioned much, needs a little details. Talking with CrawfordCurrie in IRC this morning (I hadn't gone to bed yet, but it was after midnight), we settled on the syntax for that, though if anyone has some overlooked issues, it's not set in stone yet, just in code.

The idea is that if values is enabled and the possible value has an unescaped = in it, we split on the first unescaped =, use the first half to represent the text to be displayed for the option, and the second half represents the value that corresponds to that option.

-- EricSchwertfeger - 09 Oct 2005

Well, Dakar Beta 3 has an interesting fix to the multiple parameters issue. Basically, it triggers the multiple parameter for any field starting with checkbox or having +multi anywhere in it. Which, of course, is nice and generic (any form-based plugin could invoke it, no module specific knowledge used), serves my purposes, and doesn't induce any side effects. Good Job.

I'll be posting my plugin (using the + syntax, since that's what triggers the joining of the fields) soon, probably within the next few hours, assuming I don't encounter any surprises on how to submit a plugin.

-- EricSchwertfeger - 11 Oct 2005

ExtendedSelectPlugin has been uploaded.

-- EricSchwertfeger - 11 Oct 2005

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdiff multi.diff r2 r1 manage 5.8 K 2005-08-31 - 12:32 KaoruMaeda Patch for Form.pm and EditTablePlugin.pm
Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r15 - 2005-10-11 - EricSchwertfeger
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.