Using Zen Mojo
Background Information and Tasks
[Home] [Back] [Next]
InterSystems: The power behind what matters   
Class Reference   

As background for the following chapters, this section describes basic techniques that you can use when you define client methods in Zen Mojo. It also contains a section on naming conventions to consider before starting to create Zen Mojo applications. It discusses the following topics:

General-Purpose Client Variables and Functions
For reference, this section lists some key general-purpose variables and functions that you can use within a Zen Mojo client method:
For other variables and functions provided by InterSystems, see Client Side Functions, Variables, and Objects in Developing Zen Applications. For additional standard JavaScript options, see any suitable JavaScript documentation.
Stashing Values
In some cases, you may want to temporarily save client-side data so that you can use it within multiple layouts. For example, it may be necessary to collect data from the user via multiple layouts before submitting that to the server. Or you might want to display data from one layout within a different layout. Or you might need to keep track of an internal identifier. In such cases, you can stash values and then later use them. To stash a value, save it in a property of the page instance or the template instance, depending on your preference.
When you no longer need the stashed value, use delete to remove it. For example:
delete this._MyNewValues;
Converting a JSON Object to a String
Zen Mojo packages all communication between the client and server as JSON objects, as follows:
When you stash values, however, it is important to remember that you can stash only single JavaScript values (not objects). If you need to stash an entire JSON object, first use the utility method JSON.stringify(), which takes one argument, the JSON object, and returns a string. Then stash the returned string.
The JSON.stringify() utility method is available in client methods.
Establishing Naming Conventions
It is worthwhile to establish naming conventions to avoid confusion. This section discusses the following topics:
Zen Mojo programs are case-sensitive. Remember that a is not the same as A.
Class Names
InterSystems strongly recommends that you do not create any classes in a package called ZEN.Component using any combination of uppercase and lowercase characters. If you create a package called ZEN.Component, that interferes with the way that Zen generates client-side code.
Also, note that because a Zen Mojo application can be easily extended to use multiple templates, you might want to place your template classes in a subpackage.
Because these classes are automatically projected to XML, there is an additional consideration. If multiple classes have the same short class name (that is, the class name without the package), be sure that the NAMESPACE parameter is unique for each such class.
This rule is a consequence of the fact that the short class name becomes the name of a global XML element, and those elements must be unique in an XML namespace. In Caché, each XML-enabled class must have a unique combination of the short class name and the NAMESPACE parameter.
Method Names
InterSystems classes use case to distinguish between client and server methods. You might find it helpful to follow these conventions as well.
Kind of Method Convention for Method Name Example
Client method (that is, a method written in JavaScript) Start with a lowercase letter and use an initial capital letter for each successive word (in-word capitalization). myMethodName()
Server method (that is, a method written in ObjectScript, Caché Basic, or Caché MVBasic) Start with an uppercase letter and use in-word capitalization. (Or start with a % character, followed by an uppercase letter.) MyMethodName or %MyMethodName
Content Objects and JSON Providers
Each documentView is specified by two content objects — a data object and a layout graph, as described in The Template System,” earlier in this book. You must use the names of these objects consistently in several places in the code, so it is useful to have a convention for them. One approach is as follows:
Another approach is as follows:
Note that (via the PROVIDERLLIST parameter) the page class includes a JSON provider for each data object. For this reason, the names of the data objects also become names of the JSON providers. The terms data object and JSON provider are sometimes used interchangeably, although this book simply uses data object.
You can associate keys with many of the layout objects, and your application can end up with a large number of keys. It is particularly useful to establish a naming convention for them. A simple system would be as follows:
The name of a key cannot include a colon (:) character.