In this topic
- About class extensions
- Customize attribute validation
- Customize object event behavior
- Customize relationship behavior
- Class extensions vs. application customization
A geodatabase has out-of-the-box features, such as subtypes, domains, relationship classes, and connectivity rules to define data behavior. However, if you are unable to define data behavior using any of the out-of-the-box features, you can develop class extensions.
Class extensions are java extension classes that are developed using ArcObjects application programming interfaces (APIs) and deployed to ArcGIS. When deployed to ArcGIS, class extensions can be applied to the appropriate geodatabase object classes (tables) or feature classes in a geodatabase to enforce custom data behavior.
Typically, a class extension is developed to implement one or more of the following custom data behavior:
- Complex attribute validation rules that are not available out-of-the-box
- Custom relationships between objects (tables) and feature classes
- Listens to object events and customizes event behavior to implement complex data behavior
The following sections briefly describe the most common use case scenarios for developing class extensions.
Class extensions allow you to implement a complex or specialized attribute validation that cannot be implemented by out-of-the-box subtypes and domains. For example, consider a feature class of water pipes where pipes longer than 10 meters can be made of polyvinyl chloride (PVC) or coated steel, but shorter pipes can be made of many different materials. A class extension can be created to apply this custom validation rule on the material type attribute. See the following illustration:
In the water pipe example, valid materials are dependent on the pipe length. The usual way to implement dependent validation is with subtypes, since each subtype in the object class can have a separate validation rule (can be configured in ArcCatalog without programming). However, in the example, the dependency is on the pipe length, which is not a suitable attribute on which to base subtypes, since there is no set of discrete values. It is appropriate to create a class extension to define custom attribute validation on a combination of fields (for example, length and material) instead of one field.
The following are some of the other common custom attribute validations that can be implemented using class extensions:
- Text attribute validations using string functions (such as string comparisons) or regular expressions
- Attribute validations constrained by a combination of multiple fields
- Attribute validations using external sources, such as a data dictionary table or local file system
For more information about customizing attribute validation behavior, see Customize attribute validation.
Class extensions can be developed to intercept object events that are fired during the object creation, deletion, or modification and to customize the behavior of these events to implement complex data behavior. For example, a polygon feature class of farm fields is related to a non-spatial object class (named farms). An owner in the polygon feature class might own many farm fields. You want to maintain a total area attribute in the farms object class (table), with the value being a summation of the field areas of each owner in the polygon feature class. See the following illustration:
The preceding example cannot be implemented using out-of-the-box features, such as relationship classes and relationship rules. The solution is to develop a class extension that intercepts the object events of the polygon feature class and customize the event behavior.
- The onCreate and onChange event behavior increments or decrements the total area attribute of the farms object class by introspecting the modified polygons of the feature class.
- The onDelete event behavior decrements the total area field based on the deleted polygons of the feature class.
For more information about customizing object event behavior, see Customize object event behavior.
A geodatabase has relationship classes that are similar to relationships you can set up with a database management system. Relationship classes manage the associations between feature classes and object classes (tables), and maintain the referential integrity between the related objects.
A simple relationship class and a composite relationship class are available out-of-the-box. Object or feature classes associated by relationship classes are related object classes. Developing a class extension lets you customize the behavior of the related object events triggered by the related object classes and provides a variation of simple or composite relationships.
The following shows the relationship between utility poles and transformers feature classes:
- Related features must be maintained spatially (that is, moving or rotating the poles causes the related transformers to move or rotate with it)
- Cascade delete must be ignored (that is, the transformers must not be deleted when the related pole is deleted)
See the following illustration:
In the preceding example, creating an out-of-the-box simple relationship between feature classes cannot maintain the related features spatially. Creating a composite relationship can maintain the spatial relationship, but cannot ignore cascade deletion of the related features. The solution is to implement a class extension to customize the relationship behavior. The specified relationship between the utility poles and transformers feature classes can be achieved by the following:
- Create a simple relationship class—PolestoTransformers—with forward notification.
- Implement a class extension that can intercept the move and rotate relationship events of the utility poles feature class. Customize the event behavior to maintain the spatial relationship, filter the change, delete events from the utility poles feature class, then exclude cascade delete. Deploy the class extension to ArcGIS and apply it to the transformers feature class.
Implement class extensions to intercept any or all of the relationship events (rotate, move, changed, created), then customize the event behavior as required. If an object or feature class has multiple relationship classes, implement class extensions to filter event notifications of preferred related objects or feature classes.
For more information about customizing relationship behavior, see Customize relationship behavior.
Class extensions have the simplest and most transparent way of implementing custom behavior across all applications (ArcMap, ArcCatalog, ArcGIS Engine, or ArcGIS Server) that access a geodatabase. Custom behavior provided by class extensions are stored at the geodatabase level. Whether class extensions must be implemented depends on the scope required for the custom behavior. The majority of the available customization with class extensions can be implemented programmatically at the application level using other ArcObjects APIs.
The following table compares the benefits and drawbacks of developing custom behavior at the application and geodatabase levels (class extensions):
Application level customization
Geodatabase level customization
See Also:How to implement class extensions
Scenario: Customize attribute validation
Scenario: Customize object event behavior
Scenario: Customize relationship behavior