The attached custom module makes available a Computed Value Component which can receive a value from either a SELECT-CASE-DEFAULT value assignment, or from an IF-THEN-ELSE mathematical calculation.
I've baked it as a proof-of-concept that I'd like us to evaluate as a potential standard Webform component. In it's current state it has a few limitations and frailties (see README.txt), but I really think it would be a valuable addition to the toolbox (will gladly develop it further if sufficient interest exists). The UI is not brilliant yet, neither is all of the under-the-hood housekeeping and hand-holding complete.
Computed component values are calculated in form weight sequence meaning that the calculation of ComponentB may be influenced by the outcome of ComponentA's calculation/value assignment.
ComponentA cannot reference ComponentB whilst ComponentB is further down the form tree, because ComponentB will not yet have been calculated and will therefore have an undefined value within the context of the calculation of ComponentA.
The module currently only supports computed, email, hidden, select (but not select multiple) and textfield components as input operands (also, optionally, user-specified values). Handling for date, grid, select multiple and time submission component value arrays for condition checking and calculations would probably need to be incorporated for this to become truly useful.
Please give it a test-drive and let me have feedback.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | webform_computed_D7.zip | 22.04 KB | vernond |
| #12 | webform_computed_D6.zip | 15.09 KB | vernond |
| #5 | webform_computed-6.x-0.2.zip | 14.28 KB | vernond |
| webform_computed-6.x-0.1.zip | 13.79 KB | vernond |
Comments
Comment #1
vernond commentedActually, the more I look at it the less I can even begin to think how this would be able to reliably support processing for grids and select multiple. If anyone has a bright idea, please feel free to share.
Comment #2
botser commentedHey Vernond,
Thanks a lot, it did solve my problem. I created a questionnaire using webform at my test site and used your module to calculate the results. Overall, your module did a great job, but it was an overkill for that. All I wanted was to sum-up a bunch of fields, I had to do it in a "chain" and create many calculated fields for that, moreover, for each one of the calculated fields I used a condition of - "if X equals X" in order to make it work. A couple of times I edited the X field, and than I had to recalculate all from scratch.
A couple of ideas -
1.have an option to calculate without a condition
2. longer formulas with more than two variable - maybe even free hand formulas according to the field-key (e.g, field-key1 + field-key2 * field-key3)
3. It would be nice to be able to hide the calculated fields in the form.
I'll keep working with your module and give you more feedback.
thanks again,
Botser.
Comment #3
vernond commentedThanks for the feedback botser! Yeah, it's not nearly as quick 'n easy as spreadsheet formulas, is it? The module actually doesn't do very much that you couldn't do better and faster by writing your own plug-in module on a per form basis, but apparently not every Drupal+Webform user is a developer. There is, I think, a real need to have at least some access to calculation facility for Webforms.
Where it comes into play for us is we have a bunch of small conference registration sites that generate invoices on the fly and I keep having to manually code the calculation bits... I'd rather have the lady who sets up the forms mess around with the sums, 'cos I'm just lazy :)
1) I like your idea of enabling calculations without conditions. For the proof of concept I was happy that the same could be achieved, as you did, by just specifying an X == X condition.
2) Having longer calculations with a random number of operands is a bit of a challenge, particularly in terms of BOMDAS/BODMAS. If this module does go further I don't want to be stuck with endless support issues around debugging peoples calculations to find out why they aren't getting the answer they expect when the actual issue is that they do not properly understand operator precedence. Designing and implementing a decent UI for that is, I think, going to be a fairly extensive exercise also.
3) Sorry about the fields being visible. There's a patch I've yet to get myself clever enough to commit that enables you to mark selected components as private (only shows to users with Webform results access). On our system the computed components are all private by default. Guess we could also just make them render as hidden fields.
Thanks again for the feedback and keep it coming as you play.
Comment #4
botser commented@vernond, It was my pleasure to test-drive your module, I would be happy to do the same in the future. As for writing my own plugin-module, so indeed I am not a developer, and I don't have a clue on how to do it. I build those forms in order to have online patients well-being questionnaires (you can see some of my research products at my website ). For a non-developer, it was very hard to find calculating form functionality on the web. This functionality is useful beyond the medcial field or creating invoices, for example calculating the result of an online test for students? And Since webform is a very simple to use module, it lets regular users create custom-made forms without being a drupal expert.
As for the calculations, I don't really care about "quick n' easy", as long as it is working well. Although it can be nice to have a simpler solution for the calculations. However, I would like to know how to hide the calculated fields, those make the form look unprofessional.
Thanks again
Comment #5
vernond commented@botser - Give the attached version of the module a go. Computed fields don't show on the form and there is also a new CALCULATE option. Hopefully I'll be able to make some time to refine this lot in the nearish future.
Neat site by the way!
Comment #6
vernond commentedNotes to self:
Seems that the three sets of functionality (calculation, switch->case, if->then->else) should be three separate components (modules?). Get around the code sharing issue by making two of the components dependent on the presence of the third and keep the "shared code" there.
UI changes should put the "specify value" text boxes next to their respective component selection lists.
Sanity checking of user input on component edit page required.
The use of drupal_eval may expose a weakness for abuse.
Comment #7
botser commented@vernond, thanks a lot :)
The calculations working great, and the fields are hidden, I couldn't ask for more.
Anyway, I think maybe there should be an option of yes/no for the hidden. When the fields were visible, I have found that if the "Automatically save as draft between pages" option is checked than the calculation results can appear in the next pages. Such an option to make will allow to show the final result on the last page, something like - your score is XX
Anyway, again thanks a lot, you made my day, I would love to feedback your modules whenever you need.
Comment #8
vernond commentedCool, yeah, I'll let you know when I've committed the option to make fields private or public (would apply to most components, not only computed). Bear in mind that the "save as draft" only works for logged in (registered) users if you're planning forms with that as a feature.
If you have any further suggestions on improving the calculated components functionality I'm willing to listen.
Comment #9
botser commentedOne other issue that came up today while working on the calculations is that the computed fields formulas reset every time a field is moved in the list above it. For example, moving a page-break or creating a field and moving it up deletes all the formulas :(
We are going to work with it anyway, just very carefully.
Do you think it would also happen if you would use the field-keys instead?
Another thing, I am using "conditional rules" module as well, however, its options are in between the CALCULATE and SWITCH-CASE, that is a bit confusing.
Comment #10
vernond commentedOkay, so there is some real room for growth. Following my favourite development principal of "throw one away" (which basically means that one shouldn't be too attached to the first draft of a project) I'm going to take a day or two to rethink the whole shebang and then build something a little more rugged from scratch.
This may well mean that you will need to re-do whatever you currently have in place, so apologies in advance for the potential inconvenience. However, I'm confident that the next iteration will be a more pleasing effort and will include a Webform 7.x version also. Thanks a bundle for the testing and feedback!!
Comment #11
botser commented@Vernond it is my pleasure, and no prob. with the new calculations.
Anyway, try to think of a solution for the Grid component as well. Take a look the form I have right now , after the 3rd page all questions has the same answers, however, without the Grid it's a mess.
Also, take a look at #1095782: Add a sum up column to report talking about statistics and summing up grid-component in webform-report module. Maybe it can give you an idea of how to do it.
One last thing to consider, in the Grid questions, I'm excluding the N/A answers from the calculations. So, if a patient answered all N/A but one question, his score will be calculated only according to that question. So, I should have an option to count how many were answered not N/A.
Comment #12
vernond commentedD6 and D7 modules attached.
There are some 'cosmetic' issues to handle in the D7 version (i.e. php notices and warnings and an 'invisible border' textfield in the CALCULATE fieldset), but the functionality seems unimpaired.
I really don't know what to do with grids and select multiples, so these are still unsupported.
Dates and times can be used in comparisons assuming you use the same format as they are stored in the database.
UI has received a bit of love, but could probably be further improved.
[edit] @botser - formula's no longer go missing in action when you reshuffle fields
Comment #13
vernond commentedDoes anyone see a way to achieve this without using eval()?
Comment #14
ryan258 commentedSub
Comment #15
vivdrupal commented"Dates and times can be used in comparisons assuming you use the same format as they are stored in the database."
How to find the format of value stored in database?
Ok found it in the variables listing in phpmyadmin.
It says
date format %Y-%m-%d
datetime format %Y-%m-%d %H:%i:%s
Comment #16
vivdrupal commented"Dates and times can be used in comparisons assuming you use the same format as they are stored in the database."
Ok found it in the variables listing in phpmyadmin.
It says
date format %Y-%m-%d
datetime format %Y-%m-%d %H:%i:%s
I am trying to subtract two dates.
Using Drupal 6.17 and the module from http://drupal.org/node/1251902#comment-4922646
Have tried setting site date time format to each of them but each time get the computed value like this 2011-10-102011-09-01
Comment #17
botser commented@vernond thanks a lot for the module, for the D7 in particular. I will update as soon as I have some constructive comments.
Comment #18
vernond commented@vivdrupal - I said date/time components could be used in comparisons, there is no support yet for using them in calculations unfortunately. When the module doesn't know what to do, it just concatenates the two strings, which is what you are seeing.
@botser - cool, the latest releases have an extra setting called Private which shows fields only if user has webform results access permissions (you wanted to be able to hide them before)
Comment #19
steve_lou commentedgood job!
can i caculate more than 2 values ? and hope you can make the value caculated by ajax.
thankyou!
Comment #20
vernond commented@steve_lou - do you have any ideas on how one would create a user interface for calculating more than two values to happen? I've been unable to come up with something workable and am open to suggestions.
Comment #21
botser commented@vernond at last I had a chance to evaluate the D7 version. It is working well, although , there are some error messages when creating or updating computed fields.
This is when I create a field
And this one when I update a field
Anyway to see the computed field in work, you can evaluate your hip using the form I created - at http://www.hipain.info/content/modified-harris-hip-score-mhhs#
Comment #22
vkr11 commentedthis is great. Are you planning to release this as a project on d.o ?
Comment #23
Samgarr commentedsubscribe
Comment #24
zeezhao commented+1
Comment #25
SchwebDesign commentedvery interested and subscribing
Comment #26
firfin commentedVernond, will this become part of Webform? Or a separate (sub)module? Is there a way to check out the latest version?
Just wondering, so I know where I should place my issues, questions and maybe patches even. I have the feeling this could become a runaway thread very soon. Already support requests, subscribes and general discussion are weaving through each other here. I think there is much interest for this functionality
Downloading the D7 version from #12, will give feedback soon.
Just tell me where ;-)
Comment #27
firfin commentedLike botser in #21 I get the following while using D7 version:
Notice: Undefined index: cid in webform_computed_allow() (line 729 of [installpath]/sites/all/modules/webform_computed/webform_computed.module).
As many times as the number of webform fields already defined.
I believe its because the $component['cid'] on that line. When I chance it to $cid the errors disappear. As far as I can tell the $component array does not contain a 'cid' key. Unfortunately I don't totally understand that bit of code. So I don't know what consequences changing this has (except for making the errors disappear.) Nor can I provide a patch to fix it.
Comment #28
vernond commentedThis module has been sandboxed for further development at http://drupal.org/sandbox/vernond/1301484
Please post further issues on the sandbox issue queue.
At the time of writing, only the current D7 version of code is in the repository. D6 and some issue fixes from above will follow in a few days.
If I can get this pretty enough, usable enough and sufficiently bullet-proof I'll chat with quicksketch about adding this as a standard Webform component. Failing one or more of those conditions, I'll apply to upgrade as a separate project in a few weeks.