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:
For reference, this section lists some key general-purpose variables and functions that you can use within a Zen Mojo client method:
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.
To save a value in a property of the page instance, set a property of the zenPage
variable. The zenPage
variable is available in client methods in both the page and template classes.
Start the property name with an underscore character (_
), which ensures that this property is defined only on the client. To avoid collision with internally used property names, consider starting your property names with _myApp
or a similar short string.
To save a value in a property of the template instance, set properties of the this
variable in a client method in a template class.
Note that you can also use this
in a page class. In that context, this
refers to the page instance. To avoid confusion, it is best to choose a single context for the stashed values (page or template) and then use that context consistently.
When you no longer need the stashed value, use delete
to remove it. For example:
Zen Mojo packages all communication between the client and server as JSON objects, as follows:
To retrieve data from the server, you (indirectly) call the template method %OnGetJSONContent()
, which returns a Zen proxy object as output. Zen Mojo uses that to create an equivalent JSON object and then sends the JSON object to the client.
To submit data to the server, you call the submitData()
method of the page. As input, you must use a JSON object that contains the data.
, which takes one argument, the JSON object, and returns a string. Then stash the returned string.
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
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
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
||Start with a lowercase letter and use an initial capital letter for each successive word (in-word capitalization).
|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
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:
Use names that make the code easier to read.
Use a verb for the name of a key in a control.
Use a noun for the name of a key in any other scenario.
Adopt a hierarchical (or semi-hierarchical) set of names for related keys. For example, you might use the key name accounts
for a layout element that displays a table of accounts, and then use the key name account-detail
for a layout element that displays details for one account.
The name of a key cannot include a colon (:
© 1997-2019 InterSystems Corporation, Cambridge, MA