Last modified: 2011-10-06 11:05:51 UTC
This bug was previously reported on the talk page for the extension here: http://www.mediawiki.org/wiki/Extension_talk:Semantic_Forms#Delimiters_with_commas_and_spaces SF appears to have a stricter approach to delimiters for lists of numeric values where the property is one of Has type:Number. While in earlier versions a comma and a space were also accepted as input values, SF now accepts commas only (so the list would look like "1,2,3,4,5" rather than "1, 2, 3, 4, 5", unless a different output is specified using #arraymap). Oddly enough this limitation does not apply to alternative delimiters which may have been chosen in the template (#arraymap...) and in the form (delimiter=..). This bug - if it may be called one - is reproduced on referata here: http://scratchpad.referata.com/wiki/Special:FormEdit/Multiplevalues/Multiplevalues Just click on "Show Preview". The following error message occurs after trying to save the page or get a preview: "There were errors with your form input; see below." ==> [field] "must be a valid number". See also: http://scratchpad.referata.com/wiki/Main_Page
Hi - sorry for the lack of responses before, and thanks for creating this complete bug report. Indeed, SF doesn't handle the validation of lists of numbers correctly, and actually, I'm surprised that it ever did - certainly the Javascript isn't checking whether the input represents a list or not, so if the validation worked before, it was strictly by coincidence. The easiest solution for this would be to simply turn off validation if the input holds a list of values. Would that be alright with you? Or do you think validation is important in this case?
Hi, thanks for responding. I don't know about other SMW/SF users, but certainly turning off validation would work for me. SMW's error messages, even if they are shown after the fact, should be sufficient as far as I'm concerned anyway.
Okay, great. I just checked in to SVN a fix that turns off any validation of type when the field holds a list of values. I'm marking this bug as "fixed".
