Pains using JavaScript in Nintex Forms

Variables You define in Nintex Forms as 'Client ID javascript variable name' are containing the ID of a control not the value or property. Nintex Forms uses a copy of the jQuery library that you can access through NWF$.

To get a controls value use jQuery as You do it at the end of the script to set control values e.g.

NWF$("#" + nFieldBusinessUnit ).val()

Now You are on the right track.

I recommend You to read the jquery documentation, especially

https://api.jquery.com/category/selectors/ 

https://api.jquery.com/val/ 

https://api.jquery.com/prop/ 

So I tried this as a test:

JavaScript in Bold:

function getPlan(){
   if (NWF$("#" + nFieldBusinessUnit).val() === "BLC") {
      alert("You selected BLC");
      }
}

It looks like I do need to keep the JavaScript parenthesis to hold the JQuery name for the control variable name.

So from this test, I am assuming I should only need to adjust the variable references to the JQuery format (let's hope).

Will update when I have updated the entire script.

Fingers crossed.

So I updated the code to include the changes mentioned above and it still doesn't work despite replicating across the simple test outlined previously.

Can anyone please help point out what I am doing wrong? Do I need to add a document ready function? It's driving me a little crazy now.

Code:

*Removed

It would be exceptionally helpful to have access to an export of your form so that we could actually test this with a full set of controls, however despite that, there are a few things that I would consider fixing in your code before you continue. 

Validation: 

Leave validation to the Validation Rules inside Nintex Forms. Using this generic rule - 

isNullOrEmpty({Control:Self})‍‍

You can make sure that every field has some value before being allowed to continue. Additionally, this also guarantees that ALL of your fields are set to a logical value before you start trying to calculate the resulting Risk and Plan. 

On the Submit button (which should have 'Causes Validation' set to Yes), you can put in the Client Click portion something like: 

(function(event) {
  if (!Page_ClientValidate() || !getPlan()) {
    NWF$(".nf-validation-summary").hide();
    event.preventDefault();
  }
}(event));‍‍‍‍‍‍‍‍‍‍‍‍

This will first make sure that the form is valid (if it isn't then it'll prevent the form from submitting), and if the Page_ClientValidate() returns true (meaning the form is valid), it will run getPlan().

Writing it this way however will require you to update the getPlan() function with a return value of true or false based on your own conditions. 

ex: 

function getPlan(){
  
  var returnValue = someBooleanCondition;
  //... some magical code
  
  return returnValue;
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Conditional Logic:

Specifically, your Main Function (getPlan).

Besides trying to validate a number of fields inside of this function, it would seem that you have some condition logic that needs to be sorted out. 

The biggest culprit being

if (
      (NWF$("#" + nFieldFundingSource).val() === "Innovate UK" && totalRiskScore > 100) || 
      (NWF$("#" + nFieldFundingSource).val() === "Other UK Public Funding" && totalRiskScore > 100) || 
      (NWF$("#" + nFieldFundingSource).val() === "Horizon 20/20 or EU" && totalRiskScore > 100)) {
    planType = "A";
  } else if (
      (NWF$("#" + nFieldFundingSource).val() === "Innovate UK" && totalRiskScore > 70 && totalRiskScore < 100) || 
      (NWF$("#" + nFieldFundingSource).val() === "Other UK Public Funding" && totalRiskScore > 70 && totalRiskScore < 100) || 
      (NWF$("#" + nFieldFundingSource).val() === "Horizon 20/20 or EU" && totalRiskScore > 70 && totalRiskScore < 100)) {
    planType = "B";
  } else if (
      (NWF$("#" + nFieldFundingSource).val() === "Innovate UK" && totalRiskScore < 70) || 
      (NWF$("#" + nFieldFundingSource).val() === "Other UK Public Funding" && totalRiskScore < 70) || 
      (NWF$("#" + nFieldFundingSource).val() === "Horizon 20/20 or EU" && totalRiskScore < 70)) {
    planType = "C";
  } else if (
      (NWF$("#" + nFieldFundingSource).val() === "Direct Customer Funding" && totalRiskScore > 100) || 
      (NWF$("#" + nFieldFundingSource).val() === "Membership Drawdown" && totalRiskScore > 100)) {
    planType = "D";
  } else if (
      (NWF$("#" + nFieldProjectDuration).val() === "12 Weeks" && NWF$("#" + nFieldFundingSource).val() === "Direct Customer Funding" && totalRiskScore > 70 && totalRiskScore < 100) || 
      (NWF$("#" + nFieldProjectDuration).val() === "12 Weeks" && NWF$("#" + nFieldFundingSource).val() === "Membership Drawdown" && totalRiskScore > 70 && totalRiskScore < 100) || 
      (NWF$("#" + nFieldProjectDuration).val() === "> 12 Weeks" && NWF$("#" + nFieldFundingSource).val() === "Direct Customer Funding" && totalRiskScore > 70 && totalRiskScore < 100) || 
      (NWF$("#" + nFieldProjectDuration).val() === "> 12 Weeks" && NWF$("#" + nFieldFundingSource).val() === "Membership Drawdown" && totalRiskScore > 70 && totalRiskScore < 100)) {
    planType = "E";
  } else if (
      (NWF$("#" + nFieldProjectDuration).val() === "< 12 Weeks" && NWF$("#" + nFieldFundingSource).val() === "Direct Customer Funding" && totalRiskScore < 70) || 
      (NWF$("#" + nFieldProjectDuration).val() === "< 12 Weeks" && NWF$("#" + nFieldFundingSource).val() === "Membership Drawdown" && totalRiskScore < 70)) {
    planType = "F";
  } else if (
      (numProjectValue < 1000) || (NWF$("#" + nFieldForum).val() === "Yes") || 
      (NWF$("#" + nFieldProjectDuration).val() === "< 4 Weeks")) {
    planType = "G";
  } else if (
      (NWF$("#" + nFieldFundingSource).val() === "Core Research Project") || 
      (NWF$("#" + nFieldFundingSource).val() === "Internal Capability Funding") || 
      (NWF$("#" + nFieldFundingSource).val() === "HVM Catapult Funding")) {
    planType = "H";
  } else if (
      (NWF$("#" + nFieldBusinessUnit).val() === "BLC") && (NWF$("#" + nFieldLeadTheme).val() !== "") && (NWF$("#" + nFieldFundingSource).val() === "Direct Customer Funding") || 
      (NWF$("#" + nFieldBusinessUnit).val() === "BLC") && (NWF$("#" + nFieldLeadTheme).val() !== "") && (NWF$("#" + nFieldFundingType).val() === "Fixed Price")) {
    planType = "I";
  } else if (
      (NWF$("#" + nFieldBusinessUnit).val() === "BLC") && (NWF$("#" + nFieldLeadTheme).val() === "") && (NWF$("#" + nFieldFundingSource).val() === "Direct Customer Funding") || 
      (NWF$("#" + nFieldBusinessUnit).val() === "BLC") && (NWF$("#" + nFieldLeadTheme).val() === "") && (NWF$("#" + nFieldFundingType).val() === "Fixed Price")) {
    planType = "J";
  }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Now I have intentionally messed the formatting up a bit to make it easier to read, but there are a few issues worth noting. 

First off, there is no consistent condition that you are checking in every outcome, meaning that neither nFieldFundingSource, totalRiskScore, nFieldProjectDuration, numProjectValue, nFieldLeadTheme, or nFieldFundingType are being checked in EVERY condition. Because some of these values are not obviously set by logic prior, I'd expect that in certain instances you would meet more than one condition which is bad. I will try to show you this visually. 

Field Funding Source Condition

Field Funding Source Condition:

Project Duration Condition: 

Why is any of that important? 

Because it makes it incredibly difficult to tell when you are or are not meeting the certain conditions that you're expecting to meet. 

Ideally, there should be something that is of the highest importance which overrides all other logic based on whether or not it is true. 

For instance, is the riskRating doing most of the driving? If so, that breaks things down into three very distinct tiers. 

if (riskRating === "H") {

  } else if (riskRating === "M") {

  } else {

  }‍‍‍‍‍‍‍

That's pretty straight forward. We know that ideally we should have a riskRating, so it would make sense to set up the logic in this way. 

Additionally this also remove the need for you to write out the 'totalRisk > ?? && totalRisk < ???', because it's already been done for us when we set the riskRating variable.

Or perhaps maybe it's the Funding Source that is important. 

var fieldFundingSource = NWF$("#" + nFieldFundingSource).val();

  if (fieldFundingSource === "Innovate UK") {

  } else if (fieldFundingSource === "Other UK Public Funding") {

  } else if (fieldFundingSource === "Horizon 20/20 or EU") {

  } else if (fieldFundingSource === "Direct Customer Funding") {

  } else if (fieldFundingSource === "Membership Drawdown") {

  } else if (fieldFundingSource === "Core Research Project") {

  } else if (fieldFundingSource === "Internal Capability Funding") {

  } else if (fieldFundingSource === "HVM Catapult Funding") {

  } else {
    
  }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Either way, that leaves out certain things that seem important like the Business Unit, Funding Type, and Project Value...

Create a hierarchy of importance for your values, and trickle the logic down into discrete units that have ALL combinations accounted for. Otherwise you run the risk of selecting a combination of things that result with no planType being applied. 

Last But Not Least: 

When you put javascript into you form directly as you have, make sure to remove the comments. I have found several instances of comments totally breaking the javascript interpretation because it's evaluating it during runtime, but in a strange way (within CDATA xml brackets or something). 

It's always a good place to start when you are trying to figure out if something is actually broken. 

Final Thoughts:

A lot of what you're trying to accomplish seems as if it could be done inside of Calculated Fields right there on the form WITH validation baked in where you could not only inform your users in a more meaningful way, but also lock down certain controls that in the event that the control values that they are dependent on have not been properly filled out. 

If it wouldn't be too much trouble, again, it might be worth exporting your form so that people here can take a look at what's happening. 

Just be sure to describe any column connections necessary, and environment details (SP version, Nintex ver., etc. etc.). 

I hope that this helps. 

hi nmarples

re: Validation

I want to execute the getPlan() function before the form is submitted so that the user can see the results before submitting. 

It appeared to me that the quickest and easiest way to do that would be to make the getPlan() function do the checking for blank values and then stop the rest of the function if any was blank.

The problem of course is that NWF$("#" + nFieldPortfolioSector).val() === "" doesn't see the control as empty. It will see a value like "some choice" just fine but not blank "".

I can't figure out why it doesn't see a blank but does see a specific choice.

Right. 

Assuming that you are using a Choice Control with a Drop Down and no Fill In Choices, that particular line of Javascript should work so long as you have the variable assigned to the JavaScript ID (in the Control's Options) set to the same name as the variable you are using there. 

The reason I suggest moving your validation to individual rules on the controls is that it can show a user ALL of the problems when something is incorrect. 

The way that you have the validation set up in your getPlan() function, as soon as an error condition is met, it's alerted... but what about the errors after that? An alert isn't a particularly graceful way of indicating an error and does not visually impart the user with any information after they have closed that window.

A Validation Rule on the other hand does that very well. 

Additionally if you validated all of the fields that your function (getPlan()) relies on, you could leave your 'Client Click' set up just the way you do on your button. 

Lastly. If you'd like more pointed help, it might be worthwhile of creating a mockup form that you can export and attach here that has all of the controls which are needed for this stuff to work. 

I wouldn't worry about that bit of code I wrote as it would be unnecessary in the event that you set up Form based validation to prevent the submission of the form if things weren't filled out. 

However, to explain a bit. 

the Page_ClientValidate function is a function that is created when the Nintex Form is generated. It checks the validity of the Form's controls, and returns either a true if all of the controls passed their validation tests, or a false if any of them didn't. 

Additionally if you were to set up your getPlan function so that it would return a boolean value, writing the following: 

if (!Page_ClientValidate() || !getPlan()) {
    NWF$(".nf-validation-summary").hide();
    event.preventDefault();
  }‍‍‍‍

would basically mean that

Page_ClientValidate() would run, and if something failed because it was invalid, would return false. Because I placed an exclamation point before this function, it would invert the boolean value from false to true. Because this is an OR (||) statement. As soon as it reaches a condition that is TRUE, it would stop evaluating anything beyond that point and fall into if block. 

If Page_ClientValidate() passed, and returned true, then that value would be inverted to false. This would not fulfill the OR statement, and it would continue on to the getPlan() function. Assuming you had that function set up to return a true condition if everything inside of it worked out, and a false value if something inside failed, then the same inversion would occur. If the function returned false, then the program would continue inside of the if statement's block, prevent the default event (of submitting the form) from occurring. 

This is really just a very clever way of saying 

if (Page_ClientValidate() === false || getPlan() === false) {
   // Stop the Form From Submitting
}‍‍‍

Ultimately you would not need any of that stuff if you just validated on your controls using the Nintex Rules System. so you can safely ignore that entire example. 

However if you're interesting in learning about the Truthy / Falsey evaluation of things in Javascript, see: 

JS Comparison Table 

Truth, Equality and JavaScript – JavaScript, JavaScript… 

Truthy and Falsy: When All is Not Equal in JavaScript — SitePoint 

Yep! That's the expected (and unfortunate behavior) of the order in which form-wide validation is triggered. 

When you have Javascript in the 'Client Click' portion of your button, that gets executed before (during the 'on click' event) the Form Validation occurs (which is during the 'submit' event). 

This is where that 'Page_ClientValidate' function comes in handy. If you were to replace your Client Click JavaScript with something like: 

(function(event) {
  if (!Page_ClientValidate()) {
    NWF$(".nf-validation-summary").hide();
  } else {
    getPlan();
  }
}(event));‍‍‍‍‍‍‍

It would check the form validation FIRST, and based on whether it did or didn't pass, would either run your getPlan function or allow the submit event to fire, which would actually highlight all of the bad controls.  

note: using the code above, if the form was invalid, Page_ClientValidate() will return the boolean value of false. When that happens, it forced that Error Summary panel at the top of the form (which describes all of the reasons your form has failed validation) to turn on. However, because the validation highlighting hasn't ran (the code that puts the red boxes around the invalid controls), I opt to hide that summary panel, as it will reappear once the validation highlighting is finished during the form submission event. 

Other Observations

It seems like your validation rule is written in plain text as 

isNullOrEmpty({Self})‍

Typically the "{Self}" is highlighted as a red link, unless you have made changes to your css code. My guess is that it might actually be wrong and you either need to go into the Insert Reference Dialog (f(x) button), or you can type it in plain text as 

isNullOrEmpty({Control:Self})‍

which WILL resolve to the reference linked {Self} value. 

To test that your validation is working. remove the code from your Client Click entirely and try to submit the Preview Form using what you know to be as invalid selections. 

Interesting. 

If you ever want to pick this back up, I highly suggest making a dummy form with dummy inputs but ultimately built in the same way so that it can be exported and shared without the risk of damaging intellectual property / confidential information. 

Custom JavaScript is probably the biggest culprit of sad times in the hard streets of Nintex Forms. 

Good to hear you have a workable approach at the moment.