Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
It would be great to be able to specify numeric fields, much like is possible with CCK. Of course it would be useful to have many of the same features, such as to be able to specify min and max values, prefix and/or suffix, etc. For the sake of the summary, it would be cool to be able to specify the field should be displayed as either a cumulative total or an average.
Comment | File | Size | Author |
---|---|---|---|
#80 | webform_number-d6.patch | 32.95 KB | quicksketch |
#80 | webform_number-d7.patch | 32.2 KB | quicksketch |
#79 | webform_number-d6.patch | 32.99 KB | quicksketch |
#79 | webform_number-d7.patch | 32.23 KB | quicksketch |
#78 | webform_number-d7.patch | 31.93 KB | quicksketch |
Comments
Comment #1
mandclu CreditAttribution: mandclu commentedOK, here's a quick and dirty implementation. It would be nice to also set the field to accept only integers, or set min or max values, for instance, but this looks like it's working for me.
It should display an average of the submitted numbers on the report page too.
Comment #2
quicksketchThis doesn't seem to have any advantage over the normal textfield other than a simple validation that checks that the input is numeric. I'd prefer not to manage 2 components that are identical in code other than 6 lines to validate that it's a numeric input.
So, really, the only difference here is that you've added a validator. Why not make a system for validating fields in general, then make "Numeric" one of these validators that can apply to a textfield? The end result will have about as much additional code, but provides a much greater flexibility for validation.
The _webform_validate_number is a good start, though it should be called "webform_validate_number" and either included in webform_components.module (for starters) so that all components can use it (even though textfield is really the only one that practically will).
But, some other nice validators: email address, valid URL, Minimum length, Max length, etc.
Comment #3
mandclu CreditAttribution: mandclu commentedFirst off, it also displays different on the summary showing an average), though it might be nice to offer the choice of a sum instead.
Otherwise, I agree that there's plenty more that could be added. My thought was that the initial post would really be just a starting point for anyone, like myself, who needs to use lots of numeric fields.
Structurally, it should be identical to the email field, since that's what I used as a starting point.
Comment #4
mandclu CreditAttribution: mandclu commentedOK, here's a new version that does more useful things. For analysis, you can choose an average value, or the sum of all submitted values.
Also, you can now specify a minimum and/or maximum value, or even specify that the value must be an integer.
One issue that I'm seeing is that if I set a minimum value of zero, Drupal sees that as an empty value and doesn't save it at all. I suppose I could set a minimum of 0.000001 instead, but it would be better if the logic that evaluated the component data checked on strlen instead of empty.
Comment #5
andor.koza CreditAttribution: andor.koza commentedhi
I updated number field component to use preffix and suffix
it is based on textfield component..
Comment #6
rooky CreditAttribution: rooky commentedI want to make a numerical field that only accept numbers not text and numbers
and thanks in advance
Comment #7
mandclu CreditAttribution: mandclu commentedThe version in #4 only accepts numbers. I don't think it's fair to kill the whole issue just because one person submitted a patch that includes features you don't agree with.
Comment #8
mandclu CreditAttribution: mandclu commentedComment #9
rooky CreditAttribution: rooky commentedis there any way that u could help me solving my problem
Comment #10
quicksketchSee my comment in #2. I will not add a numeric field.
Comment #11
mandclu CreditAttribution: mandclu commentedIf the only use was validation, I would agree with you.
Already there have been submissions here to support additional functionality, such as:
- Different options (both sum and avg) for how data from the field should be summarized (what the usefulness of knowing the avg number of words from fields that collects numbers?)
- Optional minimum or maximum values
- Option to check that the value is an integer
- Option to use a prefix or suffix
In addition, I can see a bunch more things that could make this useful, such as:
- Option to provide a list of integers as a dropdown instead of a textfield
- Options to use number_format for display
The initial post was just a start, and yes, had only minor modification. Clearly there is demand for specialized number handling, and already in this thread there have been attempts to take it much further.
As for the status update, what work is needed?
Comment #12
guislutavo CreditAttribution: guislutavo commentedHey, thanks to all for yout invaluable help
But your validation codes doesnt work well for me, so I wrote my own code for the validation of the "integer" type. The validate function verify the numeric value of the content of $variable by using the functions "is_int($variable)" or "is_numeric($variable)" (for validate a numeric string). It can also verify if the number is higher than or less than another number but you have to modify this in the code.
you can program and modify as well. It is an "email" type based.
Comment #13
molavy2003 CreditAttribution: molavy2003 commentedi try use integer.inc
but it accept no value
i try any type
but it have an error
try to use number.inc
but it accept all type (like text)
Comment #14
molavy2003 CreditAttribution: molavy2003 commentedi need a true numbric filed type
Comment #15
ajhere CreditAttribution: ajhere commentedHi,
How to deploy this number.inc or integer.inc file and incorporate with the webform module?
Comment #16
quicksketchI'm reconsidering this functionality, given surge_martin's #11. I think supporting select-lists is going to be a key point here (rather than adding a "Numeric" validator to the select.inc component). I've marked #190322: If field contains numbers - Show average in the Webform analysis as a duplicate, since we can add that functionality here instead.
Comment #17
alextronic CreditAttribution: alextronic commentedStrongly subscribing.
#11 is right, specially about the number_format thing.
I have a multilingual site, where users enter numbers (integers and decimals) with different formats (1,023.33 / 1.023,33), and I'd like to be able to set/allow formatting options at some point.
Is anyone working on this? My knowledge does not allow me to code, but I can test and give feedback.
Thanks anyway
Comment #18
bcn CreditAttribution: bcn commentedIf this happens, wouldn't it be more likely to go into 3.x?
Comment #19
quicksketchYes, no new features are being added to 2.x. Thanks for the move.
Comment #20
zpyder CreditAttribution: zpyder commentedI'd like to chime in with my request or feelings on such a feature.
First off, I'm not a programmer, hate programming, and have somehow been lumped with doing a web-project involving surveys etc. The webform module looks great for this. However there is a feature I've been trying to see if it is possible for the last day or so (remember, i'm not a programmer, so it may full well be very easy to do, just not for someone inexperienced like me!)
Basically, we have a typical survey asking various demographic questions. Later on though there are two questions we ask where the user has to assign points to different things, and have them tally to 100.
Obviously the first thing I'd like to do is ensure the user just enters numbers in these fields. I'm guessing this is doable from reading through this thread if I look into the "quick and dirty" fix posted earlier, or via validation.
The second thing though is what I have been focused on currently...providing a text box on the form page, which auto updates a total of the other boxes. I know this can be done in javascript using this example:
http://javascript.internet.com/forms/auto-sum-form-boxes.html
But sadly I hit a wall with my limited knowledge in terms of figuring out how to get around the naming convention employed by the webform (IE, the hypens). It'd be great if there was an easy way to assign your own names to the forms, not just have the name appended to something else. I gave up with trying to code something automatic, and am instead focusing on trying to get something working using the additional validation php box...
Apologies if any of this is easy/already covered lots elsewhere, i'm still looking & learning.
Comment #21
alextronic CreditAttribution: alextronic commentedIMHO, Webform's "naming conventions" are actually pretty obvious:
...if you were to use javascript, the ID for your input would be:
#edit-submitted-father-element-actual-element"
It is easy and comfortable to use jQuery to do this, for example, to calculate sums of fields everytime the user enters data. See:
You can use the above together with the following, so that the user cannot enter letters, and to validate punctuaction (you will have to, first, give the class
.numero
to the fields you need this to affect, using the Form API (prefix
andsuffix
) in a custom module, so that the following gets to affect the desired fields, but of course, you can do it your own way in terms of selectors:I am using all these ways (formAPI + jQuery validation/calculations) in a 800+ fields webform and it works flawless. It takes some attention and a little time to synchronize it all, but hey, this is work!
PS. I'm sorry, I know you said you have programming, but a) I think you will need to program a bit to do what you want, and b) modules are a starting point; further modifications via custom modules are what will make the site do what we specifically need.
But of course, we're all waiting for a "number" field. I just guess it's not so easy to come up with. Anyone?
Comment #22
AlanT CreditAttribution: AlanT commentedJust needed to chime in and say that a numeric field is highly important, especially being able to do some computations in the final analysis. I came here today looking to extend the webform module in this way, as it's useless to see how many people entered a value, without any idea what the average value may be.
Also, I was highly offended by the comment above (in #10) that says, "I will not add a numeric field." This shows a complete lack of integrity in maintaining a module for the community, as a maintainer needs to be focused on what the community needs. Otherwise, don't sign up as a maintainer.
Comment #23
alextronic CreditAttribution: alextronic commentedOK, comment in #10 might not sound nice, but Quicksketch is one of the best maintainers: prompt anwswers to support requests, suggestions always pointing to the right direction, and a constant presence. I just think a numeric value is needed.
Comment #24
quicksketchIn #10 I was opposed to it, but I came around after surge_martin's excellent points in #11.
Making valid arguments is a much better way of getting things done than criticizing the maintainers.
Additionally what I said was based on the fact that anyone can create a new component and add it through an add-on module. Just because I wasn't adding it to Webform core doesn't mean it wasn't possible to create a numeric component is some other way.
Anyhow... we've got a start on a numeric component, it's not done yet. When that code is updated for 3.x and working correctly, I'll review it and likely add it to the module.
Comment #25
zpyder CreditAttribution: zpyder commentedIn reply to #21 - Thanks. Though I don't have much in the way of programming skills, I do seem to at least have the ability to stare at code and in time figure out what does what, it just takes me 50x longer than someone with the knowledge!
I think writing a module is a bit beyond me, but I'll keep the code in mind for if I figure out how to do it. I think my best course of action may be to sort something out in the extra validation section perhaps.
As to the naming convention, I know that those bits were obvious, but I had issues with the hyphenation going on. The "unobviousness" came from a brief attempt at finding something in the module code that might allow me to quickly change the #edit-submitted-father-element-actual-element" to something shorter/simpler like Form1Field1.
However it seems I'm making a little progress on the V3 beta 2 in terms of figuring out how to do things. It certainly is a well made module with a lot of functionality and an impressive amount of user support. Sometimes the responses I've read in the issues have been short and to the point, but I can appreciate that the time needed to maintain this module and the amount of questions raised require this. Certainly I don't think I've seen many other modules where most issues have got at least 1 response!
So thanks for the support, and the module, from someone with very little experience in programming, but who is learning lots and finding the module really useful!
Comment #26
alextronic CreditAttribution: alextronic commentedYou can rename that yourself, for example, if you're going to use javascript to manipulate the fields' values, just start by "naming" objects by applying their values to variables:
example:
...and then, it's all set. Start using them:
example (in a function):
(of course, go back to my comment above for validation etc.)
Comment #27
zpyder CreditAttribution: zpyder commentedThanks.
I ended up coming up with this for validation, seems to do what I wanted bar being updated live, but I think I can live without that!
Comment #28
AlanT CreditAttribution: AlanT commentedResponding to #24:
"Making valid arguments is a much better way of getting things done than criticizing the maintainers."
I agree that a positive approach is usually better, but that applies to both sides. The maintainers should also consider they don't always know how others may need to use the modules they maintain.
For example, here you say, "anyone can create a new component and add it through an add-on module." This is not true, as not everyone is a programmer. Many of us depend on programmers to make certain basic component types available to us. Whether it's part of the core module or an optional add-on module doesn't matter, as long as the capability exists somewhere.
And yes, I understand that those of us who are not programmers need to be willing to pay for certain development tasks. However, there would be less friction here if developers understood that they're dealing with all types of people, and not just other developers.
One of the reasons I've chosen Drupal as my CMS is because of the incredible flexibility to configure it as I want it rather than being forced to use it in a pre-determined configuration.
And one of the reasons I selected this module was because the description said it could do basic statistics. That's not true. The module can count, that's it. It cannot provide numeric totals, averages, or percentages, which is about as basic you can get with statistics. And trying to use a downloaded CSV file is frustrating because even fields representing numbers have been FORCED to text fields, requiring a massive amount of effort to edit the values for even the most basic statistical analysis.
If there was a better choice, I'd jump, but it seems this is as good as it gets here.
Comment #29
quicksketchOkay, I've already conceded I was wrong in #16 and #24 and I've said I'm fine with including a numeric field. Is there something else I can do here?
Comment #30
RobLoachIf there was another solution that did what Webform did, then that would be called a fork, which is generally not a good solution to a problem. We're all here trying to make Webform better so that everyone can benefit. If you want it to provide numeric totals, averages and percentages, than please help out in adding those features ;-) .
Comment #31
bcn CreditAttribution: bcn commentedquicksketch mentioned (in #16) that he thought,
Then a bit later on,
I'm a little confused whether "supporting select lists" is still key, or if some kind of numeric component, based off of surge_martin's offering is a better starting point?
Comment #32
quicksketchI think at this point we might want to start over again, surge_martin's original patch was for the 2.x version of Webform, since then there have been some major changes to the way components work. Starting with the textfield component and modifying it makes sense for starters, then we should add a "Display as select" option or make radio buttons for "Display type" as either "Text field" or "Select list".
Comment #33
hendrakieran CreditAttribution: hendrakieran commentedReferring to #12, I'm using this to accept integer-only input. It works, but when user entered zero, it's shown as blank in the submission report. Any idea?
Comment #34
quicksketchPlease do not hijack this feature request. It is not a support issue on 2.9 and the feature will not be added there.
Comment #35
mandclu CreditAttribution: mandclu commentedIn all fairness, this started as a 2.x issue, so it might be more accurate to say that the 3.x inclusion hijacked the thread. ;-)
Also, given the fact that this probably relates back to how the display logic handles what PHP considers "empty" values (to PHP 0 and "" are logically equivalent) it probably wouldn't hurt to give it some consideration.
@hendrakieran have you been able to verify that a zero is stored, and not a null or empty string?
Comment #36
hendrakieran CreditAttribution: hendrakieran commented@surge_martin, thanks for responding and my apologize for the delay. Yes, I've checked the database and the value is stored correctly as zero. Viewing detailed individual submission also confirm this. It's only when displaying the result as a table (or downloading as csv for that matter) that it shows a blank field. From the html source of the result table, the cell is empty:
Comment #37
hendrakieran CreditAttribution: hendrakieran commented@quicksketch
I'm sorry if you consider this a hijack. Since this is the thread where I found the numeric field add-on, I tot it's the best place to post feedbacks and issues.
Comment #38
hendrakieran CreditAttribution: hendrakieran commented@surge_martin
Just an update, I've fixed the 0-displayed-blank issue by replacing the empty() function call to !isset() in both _webform_table_data_integer() as well as _webform_csv_headers_integer().
Comment #39
mandclu CreditAttribution: mandclu commentedhendrakieran, can you check if the same fixes are needed for the 7.x version? If so, I think you'll be officially off the hook for hijacking the thread. ;-)
Comment #40
hendrakieran CreditAttribution: hendrakieran commentedsurge_martin, the fix is only needed for the integer.inc I downloaded from #12, nothing to do with the core webform module. So, as long as anyone use that and it is supported by any version of webform, then the answer is yes. Again, I apologize for hijacking, it was never the intention.
Comment #42
samedgecombe CreditAttribution: samedgecombe commentedIn order to install this, do I just have to copy number.inc into the webform/components folder? I tried that but it's not working i.e. I can't choose the type 'number' from the drop-down when creating new fields.
Comment #43
mghatiya CreditAttribution: mghatiya commentedSubscribing.
I understand from what I read above, that this feature has not yet been implemented. A patch which was suggested, was for version 2.x, and cannot be used in 3.x
Please let me know if I am wrong.
Comment #44
quicksketchThat's right. This feature is still planned to be implemented and added to 3.x, but it has not yet been updated/committed to the project.
Comment #45
samedgecombe CreditAttribution: samedgecombe commentedHave done my own module which incorporates number.inc but when I go to edit a submission, field of type 'number' do not show up. Where do I have to look to get them to output if I go to edit an already submitted submission?
Comment #46
abhishek.kumar CreditAttribution: abhishek.kumar commentedHi Guys,
Please have look at this to solve the numeric field issues with the webform 3.
Comment #47
Summit CreditAttribution: Summit commentedSubscribing, greetings, Martijn
Comment #48
drupov CreditAttribution: drupov commentedThanks for that.
There seems to be a problem with option "Minimum Value: " though:
Can you check that?
Comment #49
abhishek.kumar CreditAttribution: abhishek.kumar commentedYou are talking about my post or above posts ?
Comment #50
hendrakieran CreditAttribution: hendrakieran commented@abhishek.kukku (#46)
It works in validating the input once I set the type to number, however fields using this type doesn't appear in the view result page.
Comment #51
abhishek.kumar CreditAttribution: abhishek.kumar commentedYes i know that because under number type i have putted integer & float type.
Comment #52
abhishek.kumar CreditAttribution: abhishek.kumar commentedCan you provide the screenshot so that i can get it.
Comment #53
drupov CreditAttribution: drupov commentedHi,
can we have a "Maxlength:"-option here also?
Are there plans to have this module have its own project page?
Comment #54
drupov CreditAttribution: drupov commentedHi,
can we have a "Maxlength:"-option here also? Useful for entering data like social insurance number etc.
Are there plans to have this module have its own project page?
Comment #55
abhishek.kumar CreditAttribution: abhishek.kumar commentedSure i am going to add the maxlength option for it. I have request a cvs account for the same you can visit it here http://drupal.org/node/1018758. You can put your comments over there but quicksketch told me that he will add number field direct to webform itself.
Comment #56
new_B CreditAttribution: new_B commentedsubscribe
Comment #57
abhishek.kumar CreditAttribution: abhishek.kumar commentedI have fixed some bugs in this attachement. Please have a look and let me if any bug.
Comment #58
joshuasosa CreditAttribution: joshuasosa commentedIt looks like this issue was started almost three years ago (2008)? When can we expect to see this relatively small feature be implemented in webform?
Comment #59
tomrenner CreditAttribution: tomrenner commentedsubscribe...
Comment #60
quicksketch@Prizem: In case you haven't noticed, there are over 100 feature requests open for Webform at all times. It take a while to review all of them. If you'd like to see this feature in Webform, I suggest trying out the work abhishek.kukku is doing.
@abhishek.kukku: If you could file this as a patch instead of as a separate module that would also help.
Comment #61
abhishek.kumar CreditAttribution: abhishek.kumar commented@quicksketch : I want it separate module so that no one can edit the code of webform and even the guy who don't know coding will use it like other module without going through the code. For the user point of view separate module is the best option.
Comment #62
vernond CreditAttribution: vernond commentedI have created a numeric component patch for D6 (when we're happy with this lot I'll roll a D7 patch). All standard textfield features are available along with the following changes:
Validation
(see numeric_validation screenshot)
A checkbox to permit only integer values to be input;
Minimum and Maximum values for numeric range checking;
Step field which, when populated, causes the field to render as a single selection select list with options running from Minimum to Maximum, stepping as specified (i.e. a Min of 3, Max of 14, Step of 2 will result in options list of 3, 5, 7, 9, 11, 13, 14);
Selection list can be made to run in descending sequence by swapping the Min and Max values.
It can be argued that the Step field should rather fall under the Display fieldset as it affects display, but I find that it is more coherent to have it here with the Min and Max fields.
Display
(see numeric_display screenshot)
Specify number of decimal places, custom decimal point, custom thousands separator to customise the way that data displays;
When exporting data the thousands separator falls away and custom decimal point is replaced by period.
Analysis
(see numeric_nozeros screenshot)
Checkbox to force analysis processing to exclude zero/blank entries from submission count when calculating averages (i.e. submissions of 5, 11, 0, 8 gives average of 6 {24/4} if the zero submission is counted, but yields an average of 8 {24/3} when the zero submission is ignored... yes, I've had this request in the past);
(see numeric_analysis screenshot)
The analysis page shows the number of submissions;
the number of submissions that are blank/zero;
the sum of all the submissions;
the average of submissions (and indicates whether average was calculated using submission count or non-zero counter);
the range of submissions (i.e. the lowest submitted number and the highest submitted number);
the standard deviation (for the bell curve enthusiasts), also modified by whether or not zero submissions are counted as part of the 'population'.
Please test and provide feedback.
EDIT - I have left a message for abhishek.kukku to advise that I seem to have hijacked work that's been done: http://drupal.org/node/1018758#comment-5250082
Comment #63
vernond CreditAttribution: vernond commentedI am currently busy with the following fixes to patch in #62:
Fix t() strings in analysis rows;
Correct population count figure used in determining standard deviation;
Add checkbox on component edit page for user to specify whether data distribution should display on analysis page (this will be in terms of occurrence counts and percentages per standard deviation from sigma -4 through sigma +4);
Roll for D7.
Comment #64
vernond CreditAttribution: vernond commentedPatches for D6 and D7 attached.
Could some kind-hearted and all-knowing individual /please/ educate me on overriding seven themes' text-transform: uppercase on table headings? The easy way out would be to send empty headers and have the actual headers as the first data row, but that just feels silly. I imagine that there will be other themes which apply a default uppercase to headings, so I'm not planning on messing with seven theme css files.
The problem is when normal distribution table renders in analysis it should be displaying a lowercase sigma (i.e. standard deviation) in the heading, not the uppercase sigma (i.e. sum of).
Comment #65
vernond CreditAttribution: vernond commentedOne issue from the posts above that I have not addressed is rendering as other selection types. Currently, if min, max and step are populated you get a dropdown list. This could also, I suppose, be turned into a radio list, because that means it is still a single-input field. My fear is that the next request will be for a multi-select (checkbox or dropdown), which I'm not entirely sure I want to get into.
Does anyone have a good idea around enabling this optionally as either a text field, or any one of the select types, without code duplication between the select component and this numeric component?
Comment #66
vernond CreditAttribution: vernond commentedI think I better think it out again. What's the possibility of optionally 'switching on' numeric field functionality for Textfield, Select options and Grid components? That way we'd solve the numeric field requests as well as the many requests around better stats/analysis on grids etc etc.
Basically, I'm considering a way to hook in the extra configuration, validation and analysis as required.
Comment #67
quicksketchHaha, well that's what we've kind of gone back and forth on already a few times in this issue. I think the comment in #11 established a separate component as being the right way to go here.
Regarding the code so far, I think we should simplify down some of the options. Regarding thousands separator, seems like it should just be a select list with 3 options: None, "Comma (,)", and "Period (.). There's no reason why we should allow other characters in there. Same goes for decimal character.
Could we nix "Standard Deviation" and probably "Range"? We might be getting into too much detail. Or optionally, we can use the (mostly secret) $single parameter to _webform_analysis_number() to provide more information. The select component is a good example of how that works when combined with Select or Other, you can click on the link to see a list of other values that have been submitted.
Comment #68
quicksketchI think having an option for display is a better idea than automatically rendering a select list if "step" is populated.
I also agree that we don't want to do multi-value selects or checkboxes.
Comment #69
quicksketchThere a few minor Coding standards issues in these patches too:
- "break" commands should be intented two more spaces.
- There should be a space between
else
and the curly brace:else {
- Same with if statements:
if ($values['step'] != '') {
Separately, this check is awesome, I've never found a good way of checking integers:
Brilliant.
Comment #70
quicksketchA few more thoughts:
- Let's use the proper key "size" instead of "width". No need to repeat our mistakes that we made in textfield.inc.
- Let's nix the "Disabled" option.
- There's no need to force a min if a max is specified (or vice-versa). I would think a max or min of 0 to force only positive or negative numbers would be common.
Comment #71
quicksketchHere's a revised patch that *should* include all the changes I mentioned in the last 4 comments. This is a D7 patch. Let's stick to one branch or the other until we've got all the functionality we want and then we'll port to the other branch.
Comment #72
vernond CreditAttribution: vernond commented@quicksketch - Great work, I really like what I'm seeing!
- I think you're quite right about allowing blanks in min or max fields (#70)
- Need to add radio button list option (#68)
- The standard deviation code needs love
- The brilliance isn't all mine (#69), it's an extension of a tip I found in the comments somewhere on the php.net site once upon a time
- The dodgy coding standards (#69) are, indeed, all mine
Hoping to address the issues and post a patch in the next day or so.
Comment #73
quicksketchI already added these in #71. Note that I skipped the option for "Radio buttons" because I found that radio buttons were quite silly. Good form design says you should use radios for "unpredictable" options, when the user doesn't already know what's going to be in the select list. For numbers like this, it's about as predictable as you can get.
I'm a little worried about this code. I moved it under a separate page through a "More stats »" link, but even then it mostly just looks cool (to me at least). I'm worried about maintenance of this code though since I don't really understand what we're accomplishing here (without pulling out my college Stats book at least).
Comment #74
vernond CreditAttribution: vernond commentedOkay, roger on the min/max and radios.
Maintaining the standard deviation code shouldn't be a problem as the formula has not changed in some years now. The way it has been written, though, could certainly do with a cleanup so that the steps of the formula are more clearly visible and comprehensible. I did three or four comparisons with MS Excel and OOo Spreadsheet and it seemed to me that I got them sums right.
The purpose wasn't really for it to look cool :-) Actually it's an effort to get closer to the "Webform is the module for making surveys" thing.
There's an increased demand for Webform to be usable as a genuine surveys/scoring tool, which necessitates we beef up the stats capabilities somewhat (it's also the motivation behind my interest in the number component and starting on the computed_component).
Comment #75
quicksketchOkay some more drastic changes in this version. The main thing is that I've converted this entire patch to an HTML5 "number" input. Considering we're reproducing a lot of built-in browser ability, I think it only makes sense to utilize these new number types if possible. This entailed the following:
- Defining a new "webform_number" element in hook_element_info().
- Including
type="number"
in our theme_webform_number() function.- If using a number component, the attributes for "min", "max", and "step" are all output in the HTML.
- I renamed "maximum" and "minimum" to "max" and "min" so they match the HTML5 attributes min and max.
- I added server-side validation of number components to make sure that they follow the "step" property correctly if not enforced by a browser.
Note that right now the only browser that properly support number fields are Safari, Chrome, and Opera. Firefox and IE just render number fields as a textfield.
Besides these changes, I also significantly enhanced our existing tests to not only include a few number components but also to test all the validation errors. So now we've got a guarantee that min, max, and step are always obeyed by our validation.
I had to change a little bit of validation to match browser behavior and the HTML5 spec regarding "step". Previously we added an extra option to select lists if step didn't line up. Say you had a min of "1" and a max of "5", but a step of "1.5". That would result in 1, 2.5, and 4 being valid numbers. 5 is not allowed even though it is specified as the maximum. That's the way Chrome and Safari work currently at least.
This patch probably still needs some more work (not to mention the port to D6), but it's shaping up.
Comment #76
quicksketchComment #77
quicksketchOh, another consideration that I didn't mention in #75: I made specifying the "Decimal places" optional. I had set up multiple fields with a step of ".5" and couldn't figure out why my values where integers. It's because we had been forcing users to enter a decimal value in order to see any decimals at all. Now I've made an "Automatic" option (which really is just an empty string) that doesn't show decimals if there aren't any and does show decimals (up to 4 places) as needed if any exist. I found that this eliminates the need to manually set a decimal option in most cases, so I've moved its position down further in the form.
Comment #78
quicksketchA few minor changes:
- Removed "size" option entirely, as it's not supported in the HTML5 spec for number fields.
- Changed the theme_webform_number() function to only output size, min, and max attributes if not empty.
I'm going to work on the port for D6, I think we're pretty much ready to go at this point.
Comment #79
quicksketchHere's the D6 port plus a few more minor changes:
- I added webform_filter_xss() to the display of prefix/suffix properties.
- The D6 version does not support prefix/suffix on select lists, I updated help text to reflect this.
- I *restored* some support for the "size" property. Because HTML5 does not include size, I didn't want to make the end-user enter a value. Instead, I made it so that the "size" attribute is set based upon the "max" attribute, to have consistency between older browsers (which respect size) and newer browsers (which base field width on max).
Comment #80
quicksketchIn Chrome, the formatting of numbers before setting the #default_value property caused the field to appear empty (such as setting value="1000" to value="1,000"). This patch removes the formatting on input when editing a field or going between pages.
Comment #81
quicksketchThanks @mandclu, @abhishek.kukku, and especially @vernond (I've credited you on the commit) for your help on this issue. @mandclu gets extra props for the clean rational and convincing in #11.
I've committed the new number.inc file to both D6 and D7, with the hope of making the next release of Webform an "HTML5 release", with the following new issues also addressed:
#908958: Use HTML5 type="email" for e-mail field input type
#1238628: Replace date component select lists with HTML5 date field input box
It'd also be nice to include #1305826: Add support for HTML5 placeholder attribute, but I'm not sure that'll be in the cards.
In any case, the new number component is a great addition and I'm really pleased with the end result. The overall flexibility and reporting of this component really makes it stand on its own and I'm glad we've made it a separate component from the plain old textfield. This has been committed to both 3.x branches. Let's open new issues for further discussion or for addressing any bugs that were introduced in this commit.
Comment #83
quicksketchUpdating title, I was having trouble finding this issue.