Skip to main content
replaced http://drupal.stackexchange.com/ with https://drupal.stackexchange.com/
Source Link

List of issues with your code (random order):

  • You are taking $form by value, not by reference, so all changes you make to it are local, scoped to function body only. Make it my_module_validate(&$form, &$form_state) if you want to have a chance to alter form - but see next points, too.

  • You are passing values around using $form instead of $form_state - things that can change in the form's lifetime belongs to $form_state rather than $form (yes, simplification, but a good starting point). In specific case of Webform module that may be needed, but you are coding against expected practice, so you should expect some difficulties when doing so.

  • You are using validate hook for something that is not validation. You should rather prepend additional save handler for this purpose.

  • You calculate on input. Usual practice in Drupal is to save user data "as is", and do formatting and calculations at output. It allows greater flexibility and retroactive changes if algorithm change. Again, it's not set in stone, and your situation may need other approach. It's OK, as long as you remember that's not quite the way Drupal was designed to work.

Tobias KirschTobias Kirsch posted nice summary, and I fully agree with it:

What this means in your case: neither the validation nor the submission function of your form might be the right place for you to achive this. Maybe it would be better to add this calculation when the user is shown his submitted values. Honestly I think webform as a beginning might not be the right module to achieve this

List of issues with your code (random order):

  • You are taking $form by value, not by reference, so all changes you make to it are local, scoped to function body only. Make it my_module_validate(&$form, &$form_state) if you want to have a chance to alter form - but see next points, too.

  • You are passing values around using $form instead of $form_state - things that can change in the form's lifetime belongs to $form_state rather than $form (yes, simplification, but a good starting point). In specific case of Webform module that may be needed, but you are coding against expected practice, so you should expect some difficulties when doing so.

  • You are using validate hook for something that is not validation. You should rather prepend additional save handler for this purpose.

  • You calculate on input. Usual practice in Drupal is to save user data "as is", and do formatting and calculations at output. It allows greater flexibility and retroactive changes if algorithm change. Again, it's not set in stone, and your situation may need other approach. It's OK, as long as you remember that's not quite the way Drupal was designed to work.

Tobias Kirsch posted nice summary, and I fully agree with it:

What this means in your case: neither the validation nor the submission function of your form might be the right place for you to achive this. Maybe it would be better to add this calculation when the user is shown his submitted values. Honestly I think webform as a beginning might not be the right module to achieve this

List of issues with your code (random order):

  • You are taking $form by value, not by reference, so all changes you make to it are local, scoped to function body only. Make it my_module_validate(&$form, &$form_state) if you want to have a chance to alter form - but see next points, too.

  • You are passing values around using $form instead of $form_state - things that can change in the form's lifetime belongs to $form_state rather than $form (yes, simplification, but a good starting point). In specific case of Webform module that may be needed, but you are coding against expected practice, so you should expect some difficulties when doing so.

  • You are using validate hook for something that is not validation. You should rather prepend additional save handler for this purpose.

  • You calculate on input. Usual practice in Drupal is to save user data "as is", and do formatting and calculations at output. It allows greater flexibility and retroactive changes if algorithm change. Again, it's not set in stone, and your situation may need other approach. It's OK, as long as you remember that's not quite the way Drupal was designed to work.

Tobias Kirsch posted nice summary, and I fully agree with it:

What this means in your case: neither the validation nor the submission function of your form might be the right place for you to achive this. Maybe it would be better to add this calculation when the user is shown his submitted values. Honestly I think webform as a beginning might not be the right module to achieve this

added 468 characters in body
Source Link
Mołot
  • 21.9k
  • 8
  • 59
  • 112

List of issues with your code (random order):

  • You are taking $form by value, not by reference, so all changes you make to it are local, scoped to function body only. Make it my_module_validate(&$form, &$form_state) if you want to have a chance to alter form - but see next points, too.

  • You are passing values around using $form instead of $form_state - things that can change in the form's lifetime belongs to $form_state rather than $form (yes, simplification, but a good starting point). In specific case of Webform module that may be needed, but you are coding against expected practice, so you should expect some difficulties when doing so.

  • You are using validate hook for something that is not validation. You should rather prepend additional save handler for this purpose.

  • You calculate on input. Usual practice in Drupal is to save user data "as is", and do formatting and calculations at output. It allows greater flexibility and retroactive changes if algorithm change. Again, it's not set in stone, and your situation may need other approach. It's OK, as long as you remember that's not quite the way Drupal was designed to work.

Tobias Kirsch posted nice summary, and I fully agree with it:

What this means in your case: neither the validation nor the submission function of your form might be the right place for you to achive this. Maybe it would be better to add this calculation when the user is shown his submitted values. Honestly I think webform as a beginning might not be the right module to achieve this

List of issues with your code (random order):

  • You are taking $form by value, not by reference, so all changes you make to it are local, scoped to function body only. Make it my_module_validate(&$form, &$form_state) if you want to have a chance to alter form - but see next points, too.

  • You are passing values around using $form instead of $form_state - things that can change in the form's lifetime belongs to $form_state rather than $form (yes, simplification, but a good starting point). In specific case of Webform module that may be needed, but you are coding against expected practice, so you should expect some difficulties when doing so.

  • You are using validate hook for something that is not validation. You should rather prepend additional save handler for this purpose.

  • You calculate on input. Usual practice in Drupal is to save user data "as is", and do formatting and calculations at output. It allows greater flexibility and retroactive changes if algorithm change. Again, it's not set in stone, and your situation may need other approach. It's OK, as long as you remember that's not quite the way Drupal was designed to work.

List of issues with your code (random order):

  • You are taking $form by value, not by reference, so all changes you make to it are local, scoped to function body only. Make it my_module_validate(&$form, &$form_state) if you want to have a chance to alter form - but see next points, too.

  • You are passing values around using $form instead of $form_state - things that can change in the form's lifetime belongs to $form_state rather than $form (yes, simplification, but a good starting point). In specific case of Webform module that may be needed, but you are coding against expected practice, so you should expect some difficulties when doing so.

  • You are using validate hook for something that is not validation. You should rather prepend additional save handler for this purpose.

  • You calculate on input. Usual practice in Drupal is to save user data "as is", and do formatting and calculations at output. It allows greater flexibility and retroactive changes if algorithm change. Again, it's not set in stone, and your situation may need other approach. It's OK, as long as you remember that's not quite the way Drupal was designed to work.

Tobias Kirsch posted nice summary, and I fully agree with it:

What this means in your case: neither the validation nor the submission function of your form might be the right place for you to achive this. Maybe it would be better to add this calculation when the user is shown his submitted values. Honestly I think webform as a beginning might not be the right module to achieve this

Source Link
Mołot
  • 21.9k
  • 8
  • 59
  • 112

List of issues with your code (random order):

  • You are taking $form by value, not by reference, so all changes you make to it are local, scoped to function body only. Make it my_module_validate(&$form, &$form_state) if you want to have a chance to alter form - but see next points, too.

  • You are passing values around using $form instead of $form_state - things that can change in the form's lifetime belongs to $form_state rather than $form (yes, simplification, but a good starting point). In specific case of Webform module that may be needed, but you are coding against expected practice, so you should expect some difficulties when doing so.

  • You are using validate hook for something that is not validation. You should rather prepend additional save handler for this purpose.

  • You calculate on input. Usual practice in Drupal is to save user data "as is", and do formatting and calculations at output. It allows greater flexibility and retroactive changes if algorithm change. Again, it's not set in stone, and your situation may need other approach. It's OK, as long as you remember that's not quite the way Drupal was designed to work.