Javascript Changes to be aware of in Commander v4.2

Javascript-reflection had been available in versions of ElectricCommander prior to 4.2. However the presence of javascript-reflection caused troubles in parsing certain paths for customers and was also deemed to be a security risk since users were not meant to be able to have access to meta-data involved in Commander properties. As such, an update to the underlying javascript engine being used inside ElectricCommander was applied in 4.2.0. This update has resulted in unexpected changes in behavior, some of which have already been corrected or are being corrected in the up-coming 4.2.3 release.

The list of changes and potential impacts to your environment are shown below. Please review the impact these issues may have on your existing code in considering waiting for the 4.2.3 version to be released (target date: end of September, 2013), or you may consider applying coding adjustments directly.

1) .toArray used in email notifier samples

The html_jobTemplate notifier example shown in the on-line help referred directly to the use of the .toArray construct. The sample notifiers provided under the <installdir>/src/samples/notifiers directory were updated to remove this reference sometime before the 4.0 release, however the on-line help example still showed the .toArray reference. This template was fixed in the 4.2.1 release. If you have the .toArray code in use inside any email templates, you should update your notifier to reflect the following change to avoid referring to the .toArray construct.

   var a = myJob.steps.toArray(); 
   for (var i = 0; i < a.length; ++i) 
   { 
      doSomething(a[i].name); 
   }

Should now become:

for (var a in myJob.steps) {  # also note item (6) below regarding reference to .steps if running v4.2.0 
  var thisStep = myJob.steps[a];
  doSomething(thisStep.name);
}

$[/javascript
  var obj = new object;
  var res = new String("\n");

  res += "<table cellspacing=\"1\">\n";
  res += <tr><td>Name</td><td>result</td></tr>\n";
   for(var a in myJob.steps) {     # assign array pointer to a
    var thisStep = myJob.steps[a]; # get String from array object using it's pointer "a"
    res += "<tr><td>" + thisStep.name + "</td><td>" + thisStep.outcome + "</td></tr>\n";
   }

res;

Any other references to java reflection in your code will have to be adjusted using different techniques, as required. Java reflection was not an advertised aspect of commander, so very few if any customers will be impacted by this change apart from the reference to the notifier mentioned above.

2) Test for NULL & Undefined no longer working

Javascript code that tests for Null or whether a property is Undefined have been resulting in unexpected results
This issue has been corrected in the upcoming 4.2.3 version

3) Test with typeof against a string is changed

The following conditional was provided inside a block of code presented in KBEC-00097

if (typeof (propertyVal) == 'string') {

The typeof construct will now return an object instead of a string result. So this code could be adjusted to the following:

if (typeof (propertyVal) == 'object') {

The code will be updated as follows after 4.2.3 becomes available:

if (typeof (currentProperty.value) != 'undefined') {
retVal += propertyName + ' - ' + currentProperty.value + '\n';
}

This issue is anticipated to be repaired in the upcoming 4.2.3 release

4) “/increment” no longer atomic

In some cases, it was noted that use of the following construct within javascript would not behave atomicly:

getProperty("/increment samplePropertyName")

This problem has been corrected in the up-coming 4.2.3 version

5) Use of myObject.getProperty(“/increment …”) inside Javascript creates it’s own scoped property

The following sample code shows a situation where v4.2.2 would create it’s own scoped property called “numberOfRetries” that could not be referenced by subsequent Javascript code blocks. eg:

$[/javascript mySubjob.outcome == "error" && myState.getProperty("/increment numberOfRetries")>= 3; ]

This has been corrected in the upcoming 4.2.3 version

6) Reference to .steps not working in 4.2

Any reference to .steps (eg: myJob.steps or myJobStep.steps) would result in an error. If you encounter this problem, you can work-around it by referring to .jobSteps instead.
This was repaired in the 4.2.1 version.

7) Change in behaviour when using a property/propertysheet named “project”

Referencing $[project] was discovered to not be consistently replaced with the expected property
This was caused by javascript picking up a project object such that a reference to $[project] would return the actual name of the project, rather than the property value that was presented in pre-4.2 versions.
Should you have a property called “project” in your system, and are encountering this problem, please contact Electric Cloud support and we can offer assistance with adjusting your reference to get the desired value.
Some examples of changes required under javascript if referencing a propertty named "project", are as follows:

Change $[/javascript myJob['project'];] to $[/javascript myJob.propertySheet.project;]
Change $[project] to $[propertySheet/project]
Change myJob['project'] to myJob['propertySheet/project']

8) Properties of different types cannot be equated without defining their types to "String"

if ((myStep.stepName) == (myJob['Restart Step'])) {...

should be changed to

if (String(myStep.stepName) == String(myJob['Restart Step'])) {...

Comments

Promoted articles