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.

Comments

Status:Active» Needs review
StatusFileSize
new2.64 KB

OK, 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.

Title:Numeric fieldsNumeric validators
Status:Needs review» Needs work

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

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

StatusFileSize
new3.05 KB

OK, 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.

StatusFileSize
new2.99 KB

hi

I updated number field component to use preffix and suffix
it is based on textfield component..

Title:Numeric validatorsNumeric field
Version:5.x-2.0» 6.x-2.0-beta1
Assigned:Unassigned» rooky
Priority:Normal» Critical
Status:Needs work» Closed (won't fix)

I want to make a numerical field that only accept numbers not text and numbers
and thanks in advance

Version:6.x-2.0-beta1» 5.x-2.0

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

Status:Closed (won't fix)» Needs review

Version:5.x-2.0» 6.x-2.0-beta1

is there any way that u could help me solving my problem

Status:Needs review» Needs work

See my comment in #2. I will not add a numeric field.

If 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?

StatusFileSize
new2.72 KB

Hey, 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.

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

i need a true numbric filed type

Hi,
How to deploy this number.inc or integer.inc file and incorporate with the webform module?

Title:Numeric fieldNumeric field
Version:6.x-2.0-beta1»
Priority:Critical» Normal

I'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.

Version:» 6.x-2.7

Strongly 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

Version:6.x-2.7» 6.x-3.x-dev

If this happens, wouldn't it be more likely to go into 3.x?

Yes, no new features are being added to 2.x. Thanks for the move.

I'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.

IMHO, Webform's "naming conventions" are actually pretty obvious:

<fieldset id="father_element">
  <input id="actual_element" />
</fieldset>

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

$('.numero').blur( function {
$v1 = '#edit-submitted-father-element-input-amount-1'; //text field
$v2 = '#edit-submitted-father-element-input-amount-2'; //text field
$vv= '#edit-submitted-father-element-result-field'; //text field; maybe attr=readonly
var t = parseFloat($($v1).val()) + parseFloat($($v2).val());
var t = Math.round(t*100)/100;
if (isNaN(t)==false) { $($vv).val( t ); } else { $($vv).val(''); }
});

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 and suffix) 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:

$(document).ready(function() {
$(".numero").keydown(function(event) {
// Allow only backspace, delete, tab, comma, period, hyphen..
if ( event.keyCode == 46 || event.keyCode == 8 || event.keyCode == 9 || event.keyCode == 190 || event.keyCode==109 || event.keyCode==37 || event.keyCode==39 || event.keyCode == 188 ) {
// let it happen.
}
else {
// Ensure that it is a number and stop the keypress
if (event.keyCode < 48 || event.keyCode > 57 ) {
event.preventDefault();
}
}
});
});

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?

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

OK, 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.

In #10 I was opposed to it, but I came around after surge_martin's excellent points in #11.

I'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 as a duplicate, since we can add that functionality here instead.

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.

In 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!

You 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:

var Form1Field1 = document.getElementById("#edit-submitted-parent-fieldset-first-element");
var Form1Field2 = document.getElementById("#edit-submitted-parent-fieldset-second-element");
var Form1Field3 = document.getElementById("#edit-submitted-parent-fieldset-third-element");
var ResultField = document.getElementById("#edit-submitted-parent-fieldset-result-element");

...and then, it's all set. Start using them:

example (in a function):

var r = Form1Field3.value + Form1Field3.value;
ResultField .value = r;

(of course, go back to my comment above for validation etc.)

Thanks.

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!

$val1 = $form_values['submitted_tree']['1'];
$val2 = $form_values['submitted_tree']['2'];
$val3 = $form_values['submitted_tree']['3'];
$val4 = $form_values['submitted_tree']['4'];
$val5 = $form_values['submitted_tree']['5'];
$sum = $val1 + $val2 + $val3 + $val4 + $val5;
$check = 10;
if (strlen(trim($val1)) > 0 && !ereg('^[0-9]+$', $val1)) {
  form_set_error('submitted][val1', t('Field 1 contains invalid characters. Only numbers are allowed!'));
}
if (strlen(trim($val2)) > 0 && !ereg('^[0-9]+$', $val2)) {
  form_set_error('submitted][val2', t('Field 2 contains invalid characters. Only numbers are allowed!'));
}
if (strlen(trim($val3)) > 0 && !ereg('^[0-9]+$', $val3)) {
  form_set_error('submitted][val3', t('Field 3 contains invalid characters. Only numbers are allowed!'));
}
if (strlen(trim($val4)) > 0 && !ereg('^[0-9]+$', $val4)) {
  form_set_error('submitted][val4', t('Field 4 contains invalid characters. Only numbers are allowed!'));
}
if (strlen(trim($val5)) > 0 && !ereg('^[0-9]+$', $val5)) {
  form_set_error('submitted][val5', t('Field 5 contains invalid characters. Only numbers are allowed!'));
}
if ($sum != $check) {
form_set_error('', t("Please ensure that the points total 10. <BR>Current total is: $sum"));
}

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

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.

Okay, 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?

If there was a better choice, I'd jump, but it seems this is as good as it gets here.

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

quicksketch mentioned (in #16) that he thought,

... supporting select-lists is going to be a key point here (rather than adding a "Numeric" validator to the select.inc component)

Then a bit later on,

...we've got a start on a numeric component, it's not done yet...

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?

I 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".

Version:6.x-3.x-dev» 6.x-2.9

Referring 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?

Version:6.x-2.9» 6.x-3.x-dev

Please do not hijack this feature request. It is not a support issue on 2.9 and the feature will not be added there.

In 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?

@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:

<td>something</td><td></td><td>somethingelse</td>

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

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

hendrakieran, 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. ;-)

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

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

Subscribing.

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.

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

That'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.

Version:6.x-3.x-dev» 6.x-3.4

Have 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?

Status:Needs work» Needs review
StatusFileSize
new3.75 KB

Hi Guys,

Please have look at this to solve the numeric field issues with the webform 3.

Subscribing, greetings, Martijn

Thanks for that.

There seems to be a problem with option "Minimum Value: " though:

  • if I set it to "1" the webform accepts 0 or negative numbers?
  • I set it to "2" the webform wouldn't accept 1 but would again accept 0 or negative numbers?

    Can you check that?

  • You are talking about my post or above posts ?

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

    Yes i know that because under number type i have putted integer & float type.

    Can you provide the screenshot so that i can get it.

    Hi,

    can we have a "Maxlength:"-option here also?

    Are there plans to have this module have its own project page?

    Hi,

    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?

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

    subscribe

    StatusFileSize
    new3.85 KB

    I have fixed some bugs in this attachement. Please have a look and let me if any bug.

    It 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?

    subscribe...

    Status:Needs review» Needs work

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

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

    Assigned:rooky» vernond
    Status:Needs work» Needs review
    StatusFileSize
    new22.03 KB
    new10.96 KB
    new5.54 KB
    new29.28 KB
    new18.49 KB

    I 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

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

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

    One 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?

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

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

    Haha, 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.

    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.

    I think having an option for display is a better idea than automatically rendering a select list if "step" is populated.

    Element type:
    (•) Text field
    ( ) Select list
    ( ) Radio buttons

    I also agree that we don't want to do multi-value selects or checkboxes.

    There 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:

    is_int($values['step'] * 1)

    Brilliant.

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

    StatusFileSize
    new22.25 KB

    Here'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.

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

    - I think you're quite right about allowing blanks in min or max fields (#70)
    - Need to add radio button list option (#68)

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

    - The standard deviation code needs love

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

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

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

    StatusFileSize
    new32.21 KB

    Oh, 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.

    StatusFileSize
    new31.93 KB

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

    StatusFileSize
    new32.23 KB
    new32.99 KB

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

    StatusFileSize
    new32.2 KB
    new32.95 KB

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

    Status:Needs review» Fixed

    Thanks @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.

    Status:Fixed» Closed (fixed)

    Automatically closed -- issue fixed for 2 weeks with no activity.

    Title:Numeric fieldNumber component (Numeric field)

    Updating title, I was having trouble finding this issue.