Lexmark X925 Lexmark Document Distributor - Page 19

Evaluating code quality with JSLint, Understanding types of scripts, Using profile scripts

Page 19 highlights

Developing workflow solutions 19 Evaluating code quality with JSLint To check for problems in your script code during builds, you can enable the included version of JSLint. JSLint evaluates code for overall quality, including syntax, structure, and style conventions, which may help avoid runtime errors by finding issues that cause compiler errors. For more information about the specific checks carried out by JSLint, see the JSLint instructions at www.jslint.com. Note that some checks specific to the use of JavaScript with HTML are omitted from LDD. Additionally, a different comment, described in the following, is used to identify functions defined later in or outside of the script and LDD objects as global variables. When JSLint is enabled, code is parsed during project builds. Any warnings generated are shown in the Problems view. Note: If the Problems view does not appear in Eclipse, then see the documentation for Eclipse. To enable JSLint during the build: 1 In Eclipse, click Window > Preferences. 2 In the category list, expand Lexmark, and then select JSLint. 3 Select Enable JSLint. 4 If necessary, configure the checks to be carried out by JSLint, and then click OK. Note: Project builds for large solutions may be noticeably slower when JSLint is enabled. You may want to enable JSLint only while debugging. Avoiding warnings for functions and LDD objects To identify LDD objects and indicate functions defined later in or outside of the script to JSLint, use the comment /**jsLint variableName */. For example, to identify the LDD top‑level objects, include this comment in the script: /**jsLint caller,confirm,confirmTarget,context,credentials,printerIP,taskInfo */ Understanding types of scripts Using profile scripts Most workflow solution projects include at least one profile script, which, after being assigned to a profile using the Device Policy Editor, can be executed from a printer or software client. A profile script may have any file name other than the names reserved for auto‑configure scripts, and each profile script file should contain a main() function. All LDD objects are available for use in profile scripts, and profile scripts can access library scripts. The script file TestMFP.js in the TestMFP example template is an example of a profile script. Using library scripts Library scripts, which can be accessed only by other scripts, can be used to contain common functionality, such as functions for database access, logging, and progress monitoring. Each function in a library script should use objects and methods appropriate only for scripts that will call it. For example, a library script called by a scheduled script should not use prompt objects or any scan methods.

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82

Evaluating code quality with JSLint
To check for problems in your script code during builds, you can enable the included version of JSLint. JSLint evaluates
code for overall quality, including syntax, structure, and style conventions, which may help avoid runtime errors by
finding issues that cause compiler errors.
For more information about the specific checks carried out by JSLint, see the JSLint instructions at
www.jslint.com
.
Note that some checks specific to the use of JavaScript with HTML are omitted from LDD. Additionally, a different
comment, described in the following, is used to identify functions defined later in or outside of the script and LDD
objects as global variables.
When JSLint is enabled, code is parsed during project builds. Any warnings generated are shown in the Problems view.
Note:
If the Problems view does not appear in Eclipse, then see the documentation for Eclipse.
To enable JSLint during the build:
1
In Eclipse, click
Window
>
Preferences
.
2
In the category list, expand
Lexmark
, and then select
JSLint
.
3
Select
Enable JSLint
.
4
If necessary, configure the checks to be carried out by JSLint, and then click
OK
.
Note:
Project builds for large solutions may be noticeably slower when JSLint is enabled. You may want to enable
JSLint only while debugging.
Avoiding warnings for functions and LDD objects
To identify LDD objects and indicate functions defined later in or outside of the script to JSLint, use the
comment
/**jsLint
variableName
*/
.
For example, to identify the LDD top
level objects, include this comment in the script:
/**jsLint caller,confirm,confirmTarget,context,credentials,printerIP,taskInfo */
Understanding types of scripts
Using profile scripts
Most workflow solution projects include at least one profile script, which, after being assigned to a profile using the
Device Policy Editor, can be executed from a printer or software client. A profile script may have any file name other
than the names reserved for auto
configure scripts, and each profile script file should contain a
main()
function.
All LDD objects are available for use in profile scripts, and profile scripts can access library scripts.
The script file TestMFP.js in the TestMFP example template is an example of a profile script.
Using library scripts
Library scripts, which can be accessed only by other scripts, can be used to contain common functionality, such as
functions for database access, logging, and progress monitoring. Each function in a library script should use objects and
methods appropriate only for scripts that will call it. For example, a library script called by a scheduled script should
not use prompt objects or any scan methods.
Developing workflow solutions
19