rock pic test5

Why Parameters and Local Variables in HotDocs 11 Rock Document Generation

Document Services

A few years ago, one of my midlife crises was to take an introduction-to-programming class. Previously, I had come from a right-brain, literary background where authenticity and “originality” were given top place. Every project was to be a work of art. So, for my programming class, I wanted to write every program from scratch, ensuring what I perceived to be the most efficient approach, adding my own artistic touch, making it mine. Imagine my surprise when I found that programmers encourage, even wholeheartedly embrace, a sort of plagiarism: Reusable Code. Why rewrite functions (think “scripts” or “computations”) that already work, not only here, but there, and everywhere?

The idea is to take a model block of code—a code template, if you will—that you can use wherever applicable, passing variable information to its placeholders. The resulting output is the same, whether a string of text, a true/false value, or a number, but the “parameters” you pass to it change as needed. It’s a wonderful concept that minimizes redundancy. Along with parameters also comes the idea of local variables: variables that have their respective values only during the processing life of the function or script. With the release of HotDocs 11, both parameter and local variable functionality—no pun intended—have been introduced to the world of HotDocs scripting. At last, template developers in the world of BPM have the tools they need to increase the efficiency of their scripts, as well as ensure the reusability of them.

Parameters

One use of parameters is to have a text computation that strings together first, middle, and last names. You can then use this computation everywhere in your document and pass in first, middle, and last name values for clients, opposing parties, trustees—you name it. But you write only one computation:

/// Name: GetFullName

/// Type: Text Computation

/// Locals:

PARAM FirstName: TEXT

PARAM MiddleName: TEXT

PARAM LastName: TEXT

/// Script:

SPACE(FirstName) + SPACE(MiddleName) + VALUE(LastName)

For a client’s name, you could put «GetFullName(ClientFirstName, ClientMiddleName, ClientLastName)» in your document, passing in the values of the client’s first, middle, and last names. You can also have model computations that calculate things such as amortization or interest, output inline and block addresses, and determine the truth of certain expressions (e.g. 42), all using parameters. You can pass in text, number, true/false, and date values. There are many great uses for parameters. In turn, the benefits are fewer name, address, and calculation computations in your CMP file; cleaner code; and a more efficient approach to document generation.

Local variables

Remember all those “Temp NU” variables you created when you needed to set up temporary number variables for indexing or counting? No longer will these temporary variables clutter up your CMP file. Now you can associate these variables with the script they “live” in, so they won’t exist outside of that script. They are defined when you create the computation you will use them in. Like parameters, you can define text, number, true/false, and date types.

HotDocs Script Sharing

Another benefit of using parameters and local variables with your scripts is the opportunity to share your code template work of art with the HotDocs community. Because scripts using parameters can be globally applied, anyone can use them in document generation. So go out to the HotDocs Forum, log in, and click on HotDocs Script Sharing, then share away. The more we post our model scripts, the more we help each other and the broader HotDocs community rock document generation by facilitating the creation of more efficient document templates.

Happy scripting!