ConsoleOne provides a shared set of APIs that allow snap-ins to integrate into the ConsoleOne shell. The snap-ins share a hosting environment with the shell, including a set of common core components that implement the look and feel of the shell. The shell framework allows developers to extend the views, the menu bar, the toolbar, the status bar, and property book pages through snap-in interfaces. The shell also allows for customizing and saving user preferences.
ConsoleOne offers several different types of snap-ins, including the following:
All management and administrative functionality provided by ConsoleOne is accomplished through snap-ins. The ConsoleOne shell itself only provides a foundation upon which snap-ins can be built.
As a foundation for other snap-ins, Novell provides the console snap-in. The console snap-in extends the shell by providing a basic graphical user interface consisting of an object browser, view, main menu, toolbar, and status bar. All subsequently registered snap-ins build upon the console snap-in by further adding menus and menu items, toolbar items, status bar items, views, and so forth.
Current Novell utilities, such as NetWare Administrator and ManageWise®, are being rewritten as snap-ins to the shell. Products that currently snap in to either the NetWare Administrator or ManageWise will be rewritten as snap-ins to ConsoleOne.
Content snap-ins can provide application-level features and functionality, add a new feature to another content snap-in or extend a content snap-in to greater levels of functionality. Novell will publish and provide snap-in points into each of the major snap-ins, such as the NDS and NetWare namespaces, which can then be extended by third-party developers.
The scope of a snap-in is the set of circumstances within the ConsoleOne environment when the snap-in applies and is active.
For example, suppose you are developing a ListView snap-in that allows the objects in a selected container to be displayed in a list in the right panel of the screen. Your snap-in would be active when a container object in any ConsoleOne namespace is selected, but not when a leaf object (that has no children) is selected. To provide this capability, you would register your ListView snap-in with GlobalContainerTypesScope—one of the defined ConsoleOne scopes.
Or, if you want your snap-in to be active only when a DOS Filesystem namespace container is selected, you would register it with NamespaceContainerTypesScope, specifying "DOSNamespace" as the desired namespace.
ConsoleOne provides a Scope interface, which must be implemented by all scope classes. The scope classes that implement this interface are used to register snap-ins. They define where snap-ins apply as they are registered. The methods defined in the Scope interface are used only when you create your own scope class.
The scopes are broken down into two basic categories, Global scopes and Namespace scopes. Global scopes apply to any namespace defined for the ConsoleOne environment. Namespace scopes apply only to objects in the namespace specified when the snap-in is registered. For a complete description of snap-in scopes, see Section 2.3, Snap-In Scopes.
ConsoleOne has to know about each snap-in. All snap-ins derive from interfaces that extend the Snapin interface. However, to register each snap-in you must implement the Registration interface. The implementation of the Registration interface can be within the same class that extends the Snapin interface, or in a separate class. For the purposes of this discussion we assume you have implemented the Registration and Snapin interfaces in the same class. Whether implemented in a snap-in class or in a separate registration class, the class that implements the Registration interface must be placed in the snapin directory.
The Registration interface defines a single method, getRegistration(). At start-up, ConsoleOne calls the getRegistration() method for each participating registration snap-in. The getRegistration method returns a RegistrationItem array containing information identifying what kind of snap-in each object is, where to find it, and when ConsoleOne will load the snap-in.
Each RegistrationItem in this array is built by one of two constructors, both of which have as their first parameter the scope class, which you use for the snap-in being registered:
One constructor of RegistrationItem has two parameters: Scope and className. The Scope parameter describes the conditions under which the snap-in will appear in the ConsoleOne shell. The second parameter, className, is a string containing the full name of the snap-in class.
A second constructor of RegistrationItem has an additional parameter, instanceData. Any time you use the instanceData parameter in RegistrationItem, you must implement the Template interface in the snap-in you create in order to retrieve the instanceData object. The instanceData can be any Java object. For more information on implementing the Template interface see Writing Multiple Snap-ins in a Single Class.
Depending on the type of snap-in you are writing (namespace, view, menu, toolbar, status bar, etc.), only certain scopes can be used. For more information, see Section 2.3, Snap-In Scopes.
The ConsoleOne shell can auto-register all snap-ins in a collection by loading each class file in the collection. Snap-in classes are packaged into JAR collection files and placed in the Snapins directory relative to where ConsoleOne is installed. At start-up, the ConsoleOne shell then auto-registers all of the snap-ins in such JAR collections by loading each class file in the collection which implements the Registration interface. In a process called introspection, the shell checks each class found in the JAR file to see if it implements the Registration interface, and if so, calls its getRegistration() method.
IMPORTANT:The directory structure in your JAR file must match your Java package structure.
To prevent every class in a large snap-in collection from being checked, you can include a manifest file in the JAR file that identifies which classes implement the Registration interface. This should be done when many of the classes in a large collection are merely "supporting classes," since ConsoleOne can quickly load the appropriate registration classes without inspecting all the classes in the JAR.
The JAR collection file contains identification information which is provided in the header section of the manifest file. The information that the shell is looking for includes the registration collection name, the registration collection description, the developer’s copyright string, the snap-in collection version, and the version of the shell to which the package was written. Each class listed in the manifest file that includes the tag "Snapin-Registrar:True" will be registered by ConsoleOne. All other classes will be ignored. (See the sample manifest file described in Registration Using a Manifest File.)
Why Create a Namespace Snap-in
As a framework for the management and administration of networks, ConsoleOne provides the capability to display network objects or resources in an organized fashion. These network objects and resources are typically represented within logical namespaces (NDS, LDAP, NetWare® File Systems, NT Domains, and so forth) or physical namespaces (internetwork or segment maps, inventory databases, etc.). These namespaces provide context, that is, the logical relationship, such as location in an organizational structure, and/or the physical relationship, such as physical wire segmentation, routing, and so forth of these network objects and resources.
A namespace, therefore, defines a set of objects, how they are named, and the relationship, structure, hierarchy, or containment of those objects. In addition, an object within one namespace can provide a link to another namespace. In NDS, for example, a NetWare volume, as an NDS object class, represents a volume within the NetWare file system. NDS, as a namespace, uses the NDS Volume object as a bridge into the NetWare file system, which is another namespace.
In order to manage and administer network objects or resources, they must first be described by a namespace snap-in. It is through the namespace that the features and functions of the represented objects and resources are exposed and presented to the end user.
In order for a set of network objects or resources to be managed or administered through ConsoleOne, they must be made accessible through ConsoleOne. The namespace is the method by which ConsoleOne is able to enumerate and display the objects or resources of a network or computing environment. Novell provides NetWare and NDS namespaces. Through the NDS namespace, the end user will be able to view and manage NDS objects, and through the NetWare namespace, the end user will be able to view and manage NetWare objects.
Not all developers must write a namespace snap-in. For example, developers who extend the NDS schema with new objects need not write a new namespace snap-in. The NDS namespace will enumerate the new object types based on the NDS schema. However, they might write other snap-in methods to provide property-editing capability for those new object types.
Services that are built around NDS, or that extend the capability of NDS into other environments, might create a new namespace snap-in. Another example might be a file system that could be managed through ConsoleOne. In order for ConsoleOne to enumerate and display the objects represented by that file system, a namespace snap-in must be written.
View provide a related presentation of a namespace object. A view can simply be a listing of the subordinates of the selected object, or it can be more detailed, such as a table or graph. What the view presents and how it is presented is largely determined by the namespace and what it represents.
One or more views can be associated with any namespace, or with a particular object type within a namespace. As an example, NDS is typically represented in both a hierarchical and a list fashion. A view snap-in could provide an alternative logical view for a specific class of object. Other examples include a topographic view of the network, a detailed view of an object, or an in-place file viewer.
When an namespace object is selected, ConsoleOne examines the set of participating snap-ins registered with the namespace or object type, and determines whether or not multiple views are available. If multiple views are available, the view menu then lists the views from which the user can select. When a view becomes active (either by menu, activation by a namespace, or object selection), then additional menu, toolbar and status bar items also become active because they are snap-ins registered to the view.
The ConsoleOne console view provides limited display capability. As such, it might not provide the presentation that is most appropriate for a given namespace. Novell provides views that are specifically designed for a basic set of day-to-day tasks, such as managing NDS objects and managing the replicas and partitions of NDS.
A view should provide a presentation that makes the namespace and objects it represents easily accessible, and thus supports the tasks and functions related to those objects or namespace.
A view makes it possible to structure the tasks based on the presentation. In some cases, a task is better suited for a particular view. For example, managing a large number of objects or object types is difficult in a standard list-type view. A view that better utilizes the available screen space might be a wrapped list, which would be better suited to managing large numbers of objects. A map-type view is typically more suited to managing the topology of the network because it generally establishes a better relationship between the nodes on a LAN.