Package wt.vc.views

See:
Description

Interface Summary

ViewManageable	Versioned objects that implement ViewManageable indicate that they can participate in views.
ViewService	This service interface provides the general APIs needed to work with View and ViewManageable objects and manage them with the ViewService; Views can be placed in hierarchies using ViewAssociation links.

Class Summary

LoadView	Creates and persists views and view associations based on input from a comma seperated value (csv) file.
LoadViews
StandardViewService	This implementation of ViewService caches the Views and ViewAssociations, so ViewService calls do not hit the database.
StandardViewService.ViewCacheUpdater
View	The view represents a type of branching mechanism for versioned data.
ViewAssociation	Views are associated using ViewAssociations, forming parent-child networks.
ViewCache	A cache of all View and ViewAssociation objects.
ViewHelper	This standard helper for ViewService has helper methods and accesses API functionality via ViewHelper.service.
ViewReference	The ViewReference is an ObjectReference particular to Views.
ViewReferenceSearch	Search for a reference to the View listed.
ViewServiceFwd	This service interface provides the general APIs needed to work with View and ViewManageable objects and manage them with the ViewService; Views can be placed in hierarchies using ViewAssociation links.

Exception Summary

ViewException

The ViewException represents a type of exception that may be thrown by methods in this package when invalid or abnormal conditions occur.

Package wt.vc.views Description

vc package - Version Viewing Service

The views package introduces the concept of ViewManageable versions. In many enterprises, the development of a product is such that a group may work on it to a certain point, hand it off to another group that makes value-added changes, and so on. While a downstream group is working against a handed-off version, the upstream group can continue to work on it.

In a simple example, the Engineering group releases revision A of a part to the Manufacturing group. At this point, the Manufacturing group restructures the part, making necessary changes for production purposes while the Engineering group begins work on revision B of the part.

The views package captures such a process. The Engineering and Manufacturing groups are represented by Views. These views can be associated in a manner that encapsulates the process. For example, the Manufacturing view becomes a child of the Engineering view. Engineers can then assign their ViewManageable data (parts in this example) to views, indicating that these objects are view-dependent and can be identified as Engineering or Manufacturing data. Most ViewManageable objects are assigned to the root view, because it is generally not the responsibility of downstream views to create new data as much as to modify the data to fit requirements. However, phantom parts are parts that the manufacturing group might create when a group of parts are actually pre-built.

The Windchill model builds view management capabilities on top of the existing versioning capabilities. A ViewManageable version, when assigned to a view, is qualified by the view. When a downstream group is ready to accept and add value to the version, it branches its own version (qualified by its view). The following example illustrates this concept.

• The Engineering group creates part 100, assigning it to the Engineering view. The version of this part is A.
• After several iterations, part 100 is released.
• The Manufacturing group branches part 100, creating version A.A of part 100, which is assigned to the Manufacturing view.
• Meanwhile, the Engineering group revises part 100, creating version B (which is also assigned to the Engineering view).
• The Manufacturing group releases version A.A and puts it into production.

ViewManageable versions have the following characteristics:

• The view a ViewManageable version is assigned to can not be changed once persisted. In the preceding example, version A of part 100 can not be reassigned to the Manufacturing view.
• View-dependent versions can not become view-independent and viewindependent versions can not become view-dependent. The first version of a master determines that all versions of that master are view-dependent or viewindependent.
• View-dependent versions can be branched only into downstream views. When creating a branch for a particular view from a view-dependent version, only those views that are downstream from the current view are valid for the new version. The view to which the initial version was assigned is considered the principal owner of the master; downstream views provide value-added changes.
• Branching is used as the underlying mechanism, allowing downstream views to make value-added alterations. Because this mechanism creates new versions, changes made are isolated to the branched versions, allowing concurrent development. Note that as separate versions, the view-dependent versions have independent life cycle states and can be independently lifecycle managed.
• The ViewQualification provides a qualifier for ViewManageable data. When applied, it filters out all view-dependent versions not assigned to the view specified. By default, if no view-dependent versions have been branched into the view specified, the parent views are checked until either no views remain or at least one version is assigned to a parent view. Setting parentSearched to false disables the parent-searching behavior.

Views and their associations can be created using the LoadViews application. See the Administrator's Guide for details. Views and view associations exhibit the following behavior:

• Views, once created, can not be deleted, but can be renamed.
• Views can be inserted between a parent and its children at any time. However, this is the only way to alter the structure after it has been established.

The ViewHelper and ViewService provide the functionality associated with view management. The helper provides the client-side APIs to assign the version to a view and get the view to which a version is assigned. The service provides APIs to branch view-dependent versions into downstream views, and to obtain information about the views and their associativity. When developing against this package the following should be noted:

• The service employs caching, which the ViewReference uses. It is more efficient to call the service APIs than to go to the database for view/view associativity information.
• The ViewService does not emit an event when a new version is branched in a downstream view. VersionServiceEvent's NEW_VERSION event should be subscribed to if you are interested in the creation of a new view-dependent version or branch.