All the ZOM services and features and development approaches mentioned above also apply to single-person development projects as well. In fact, these can be applied to your advantage anytime development is spread across multiple development environments regardless of the number of people involved. For example, there are often several versions of an application representing various…
Read more
Another common approach to team development projects is to maintain separate development environments for each developer and synchronize the development environments from time-to-time by merging changes from one environment directly into another. This approach is referred to as peer-to-peer development. Peer-to-peer development is similar to master-slave development except there is no master environment. Each development…
Read more
To gain more control when importing objects, you can import objects first into a “staging area” to verify the incoming objects before bringing them into the application proper. ZOM provides a staging area called the “Shadow Object Dictionary” which is a mirror image of the Zim Object Dictionary. Once in the Shadow Object Dictionary, you…
Read more
Combining ZOMImport and ZOMExport with keywording and object locking can give you a great deal of control over the management of the application as a whole. Let’s assume that the master is to receive Steve’s work, but needs to protect the application from any changes that Steve has made outside his defined task of user…
Read more
A typical configuration for projects involving multiple developers is separate development environments for each developer and a master environment that contains the combined results of the project team. This development approach is referred to as master-slave development. Each developer’s environment is called a “slave” to the “master” environment. From time to time, a developer merges…
Read more
Merging changes from one development environment into another is done by exporting the changes from the first (i.e., source) environment using ZOMExport and then importing these changed objects into the second (i.e., target) environment using ZOMImport. The import process compares the incoming objects from the source environment with the objects in the target environment. New…
Read more
When working on a team development project, you should first adjust the configuration of ZOM for each development environment so that objects from the various environments can be easily identified. The three configuration options of importance here are the environment code, the new keyword, and the changed keyword. You configure ZOM using the ZOMConfig command.…
Read more
For ZOM to know about an object, the object must first be registered. The registration process requires no effort on your part since registration is automatic and occurs when you use a ZOM service. Each ZOM service quickly searches for any unregistered objects and registers them in the knowledge base. When an object is registered,…
Read more
The Zim object definition commands (e.g., CREATE, ERASE, RENAME) operate against a single object at a time. For example, an EntitySet is created using a CREATE command. If you needed to create all of the EntitySets, you need to issue a series of these commands. ZOM, on the other hand, operates on sets of objects.…
Read more
When you “touch” an object, ZOM performs an in-depth analysis of the object and records the resulting information in its knowledge base. Objects are “touched” using a special ZOM service, ZOMTouch. For example, the following command touches the Contracts object : ZOMTouch Contracts ZOMTouch determines the object’s current state and discovers any dependencies between the…
Read more
English 
Portuguese