Categoria: ZIM User Documentation

The object dependency information can also be used to select un-referenced objects that are not used by any other object. In our example, there are three un-referenced objects: pMainMenu, PlacedBy and vJunkVar. Un-referenced objects can be selected using the “u” selection criteria, as shown in the following example:

ZOMList +p u

Objects Found by Unreferenced Criteria “+p u”

Often, objects that are not referenced are no longer in use by the application and can be destroyed. This is not always the case as shown above where the unreferenced pMainMenu, which is the root of the dependency tree, is a very significant object to this application. Another object, the role PlacedBy, could have been created in the application as a convenience to users entering ad hoc queries.

Dependency implosion is the process of finding the objects which depended on (i.e., used) by a given object, and so on down the dependency tree. There are three different kinds of implosion: immediate, creation, and program.

As an example, to list all of objects that are used by pMainMenu, enter

ZOMList pMainMenu +i

The result is the list of objects that are used by pMainMenu directly, regardless of whether the dependency is creation or program. The diagram below highlights the selected objects:

Objects Selected by “pMainMenu +i”

This selects only objects that are used by pMainMenu explicitly by means of a creation dependency or a program dependency. The objects that use these depended on objects are ignored.

Similar to dependency explosions, you can implode by either creation dependencies (using the ‘t’ option) or program dependencies (using the ‘p’ option). Now suppose we want to list only the objects that are used by pMainMenu by means of a program dependency:

ZOMList pMainMenu +i p

The diagram below highlights the selected objects:

Objects Selected by “pMainMenu +i p”

This selects only objects that are used by pMainMenu by means of a program dependency, as well as any objects that have program dependencies on these dependent objects, and so on all the way down to the leaves of the tree. Creation dependencies are ignored.

 Next suppose we want to list only the objects that are used by pMainMenu by means of either creation or program dependencies and recursively search all the way down to the leaves of the tree:

ZOMList Customers +i pt

The diagram below highlights the selected objects:

Objects Selected by “pMainMenu +i pt”

This selects objects that are used by Customers by means of any dependency, as well as any objects that have a dependency on these dependent objects, and so on all the way down to the leaves of the tree.

To list only the objects that are used by pMainMenu by means of either creation or program dependencies and recursively search all the way forward to the leaves, but not include the pMainMenu object, enter

ZOMList pMainMenu +i pth

The diagram below highlights the selected objects:

Objects Selected by “pMainMenu +i pth”

This selects only objects that are used by pMainMenu by means of any dependency, as well as any objects that are used by these dependent objects, and so on all the way down to the leaves of the tree, but not the set of objects that were used as the starting point of the implosion. This is called a hollow implosion.

In a hollow implosion, the selected object set does not contain the original objects that fed the implosion algorithm in the first place.

Dependency Explosion is the process of finding the objects which depend on (i.e., uses) a given object, and so on up the dependency tree. There are three different kinds of explosion: immediate, creation, and program.

As an example, let’s suppose we want list all of the objects that use Customers:

ZOMList Customers +x

The result is the set of objects which use Customers directly, regardless of whether the dependency is a creation dependency or a program dependency. The diagram below highlights the selected objects:

Objects Selected by “Customers +x”

This selects only objects that use Customers explicitly by means of a creation dependency or a program dependency. The objects that use these dependent objects are ignored.

Now suppose we want to list only the objects that use Customers by means of a creation dependency:

ZOMList Customers +x t

The diagram below highlights the selected objects:

Objects Selected by “Customers +x t”

This selects only objects that use Customers by means of a creation dependency, as well as any objects that have creation dependencies on these dependent objects, and so on all the way up to the root of the tree. Program dependencies are ignored.

 Next suppose we want to list only the objects that use Customers by  means of a program dependency:

ZOMList Customers +x p

The diagram below highlights the selected objects:

Objects Selected by “Customers +x p”

This selects only objects that use Customers by means of a program dependency, as well as any objects that have program dependencies on these dependent objects, and so on all the way up to the root of the tree. Creation dependencies are ignored.

 Next suppose we want to list only the objects that use Customers by means of either creation or program dependencies and recursively search all the way back to the root:

ZOMList Customers +x pt

The diagram below highlights the selected objects:

Objects Found by “Customers +x pt”

This selects only objects that use Customers by means of any dependency, as well as any objects that have a dependency on these dependent objects, and so on all the way up to the root of the tree.

 Now suppose we want to list only the objects that use Customers by means of either creation or program dependencies and recursively search all the way back to the root, but not include the Customers object:

ZOMList Customers +x pth

The diagram below highlights the selected objects:

Objects Selected by “Customers +x pth”

This selects objects that only use Customers by means of any dependency, as well as any objects that have a dependency on these dependent objects, and so on all the way up to the root of the tree. However, this does not select the set of objects that were used as the starting point of the explosion. This is called a hollow explosion.

In a hollow explosion, the selected object set does not contain the original objects which fed the explosion algorithm in the first place.

Objects are imported using the ZOMImport command. ZOMImport imports all objects described in the ASCII files produced by ZOMExport. Therefore, before you can use ZOMImport, you must first place the ZOMExport files in your database directory. Then, to invoke ZOMImport, enter

ZOMImport

You can also import Z41 files that are compatible with older versions of ZOM as shown in the following example:

ZOMImport ;f Z41

ZOMImport can also be used with the standard ZimSAVE object description files. If you want to import objects from ZimSAVE format files, enter

ZOMImport ;f DT4

Objects are exported using the ZOMExport command. The objects to export are identified using the normal object selection criteria. For example, suppose you have associated all the objects you want to export with the keyword “To_Export”. The following command exports these objects:

ZOMExport +k To_Export

ZOMExport builds a series of ASCII files containing the object descriptions. These files are placed in your database directory. By default, all files are suffixed with “.Z50” and are suitable for use with Zim version 5.0 and later.

You can also create files with suffix “Z41” which are compatible with 4.XX versions of ZOM. For example,

ZOMExport +k To_Export ;f Z41

You can also have ZOMExport build files in the standard ZimSAVE format. These files could then be imported using the standard ZimLOAD utility. (ZimSAVE creates a series of files in the database directory typically suffixed with “.DT4”.) The following exports object descriptions in ZimSAVE format:

ZOMExport +k To_Export ;f DT4

ZOM provides two special services for exchanging objects between separate development environments. Objects are exported from one environment using ZOMExport and imported into another environment using ZOMImport. These services use a machine-independent ASCII file format to exchange objects.

Objects being exchanged retain their object key identification. The object key enables ZOMImport to compare the objects being imported with the existing objects in the target environment. ZOMImport can then perform an intelligent merge of the imported and existing objects, detecting new objects, deleted objects, and changed objects.

Note: The Export and Import wizards provide a wider range of functionality when porting applications. ZOMExport and ZOMImport are suited only for exporting object dictionary definitions, where the wizards export generated applications and framework metadata.

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, it is assigned an object key that uniquely identifies it. The object key is used internally by ZOM to track the object during its lifetime, even if the object changes name or location. ZOM also uses the object key to track objects that are maintained at several separate development sites.

After registration, ZOM knows the object exists. However, at this point, ZOM knows very little about the object beyond its name, type, and object key. For ZOM to understand more about the object, you must “touch” the object.

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. ZOM enables you to select a set of objects from among the universe of objects in your application and apply an operation against that set of objects. For example, recreating all EntitySets is as simple as executing the command:

ZOMReCreate +t Ent

The “+t Ent” syntax is an example of the powerful selection criteria available for retrieving objects. In this case, “+t Ent” indicates that the Type of the object must be EntitySet. As you read in the following subsections, there are many other selection criteria, as well as operations for combining sets of objects in various ways.

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 object and the other objects it references. The source of the dependency information is Zim’s standard dependency tracking database. Zim maintains dependency information for all objects and updates this information when an object is created or a program is parsed or compiled.

Once ZOMTouch has finished processing, ZOM has a complete picture of the object and any interdependencies with other objects. This in-depth information enriches ZOM’s knowledge base and is the foundation for the powerful object analysis and manipulation you can perform with other ZOM services.

As you make changes to your application objects, this information is updated automatically if you use ZOM services. As you edit the program code, the ZOM’s knowledge of dependencies between the program object (ie document) and the objects referenced in the program becomes out of date. To update the ZOM knowledge base, “tap” the changed document objects.

Note: For more information on Zim’s dependency tracking, see SET DEPENDENCY.

Zim applications consist of collections of objects, each of which has a specific purpose and a set of features. These objects are described in the Object Dictionary. These various types of objects are

The Object Dictionary is arranged such that all objects of the same type are grouped together. This is very convenient for working with objects of the same type, but dealing with objects in general is not so easy. A simple example illustrates this point. To see the descriptions of all EntitySets with names starting with ” Inv”, enter the following command:

list all Ents where EntName like " Inv%"

To see descriptions of all objects with names starting with ” Inv”, enter the following series of steps, one for each type of object:

list all Ents where EntName like " Inv%"
list all Rels where RelName like " Inv%"
list all Roles where RoleName like " Inv%"

and so on.

ZOM, on the other hand, treats all objects the same, regardless of type, and enables you to operate on them together. This homogenous view of objects enables, for example, all objects with names starting with ” Inv” to be retrieved in a single step:

ZOMList Inv*

ZOMList, which lists information about objects, is just one of the ZOM services. As you can see from this example, treating application objects homogeneously can lead to significant time savings and very powerful operations. ZOM provides extensive capabilities for selecting and manipulating objects that operate over the entire universe of application objects.

Note: ZOM does not deal with FormField and Field objects as independent objects, but instead works with the parent objects (e.g., Forms, EntitySets, Relationship, etc.).