As the SQL repository parses the XML repository definition file, it creates an instance of your RepositoryPropertyDescriptor class and stores it directly in the SQL repository’s list of property descriptors for each item descriptor. The SQL repository calls setItemDescriptor() to associate your property with its item descriptor. The SQL repository then calls one or more methods corresponding to the property’s type:

If the property refers to another item’s type, this method:

RepositoryPropertyDescriptor.setComponentItemDescriptor()

sets the item descriptor for that type, depending on which attributes are set in the <property> tag: data-type, item-type, component-data-type, or component-item-type. They define the property’s Java class, the component’s property class (if the property is a multi-valued property), the RepositoryItemDescriptor for a scalar or a multi-valued property that refers to other item types.

If your property type can accept any of these values, you do not need to override these methods. If your property is constrained in what data types it supports (which is generally the case), you should put error checking logic into these methods to throw errors if an invalid type is specified. Your property descriptor should throw the unchecked IllegalArgumentException to provide details about what type is required. If your property type is very restrictive, you can implement these methods to return the appropriate values:

This prevents developers of repository definitions from having to set the data-type, component-data-type, item-type, and component-item-type attributes. You may still want to put error checking in these methods to signal errors if they do provide invalid values.

Caution: When an application calls the repository item method to retrieve or set a user-defined property, it calls the repository item’s own getPropertyValue() and getPropertyValue() methods, which, in turn, call the getPropertyValue() and getPropertyValue() methods that you implemented for that property. The second set of get and set methods should avoid calling the first set; otherwise, an infinite loop can occur.

The getPropertyValue method receives an extra Object pValue argument. This is set to any value found in the cache for this property name, if any, or null if no value is in the cache. The call to setPropertyValue can embed a call to setPropertyValueInCache(this, yourvalue) in order to cache this property value for subsequent method calls.

If your property is not set, you may choose to return the value of the getDefault() method on the RepositoryPropertyDescriptor. This allows the user to set the default value for this property with the default attribute in the XML tag. This method calls setDefaultValueString, which converts the default value based on the class returned by getPropertyType, which calls setDefaultValue. You may choose to modify this behavior by overriding these methods though typically this functionality is sufficient.

Note that user defined properties must be serializable. The getPropertyValue and setPropertyValue methods do not need to work on an unserialized version, but the getPropertyType, getComponentType, getPropertyItemDescriptor, and getComponentItemDescriptor methods in particular do need to work. This is important so that the ATG Control Center can understand the type of property it is editing.

To make your user-defined property queryable, it should represent a database column. Unless your user-defined property extends GSAPropertyDescriptor, the property is not queryable and you should implement the method isQueryable to return false. If you want a user-defined property to be queryable, make sure it extends GSAPropertyDescriptor. You may also override the methods isWritable and isReadable to turn off write access or read access to your property respectively. Other methods such as isHidden, isExpert can also be overridden if you want to set additional Bean attributes. The method setValue(String pName, Object pValue) is called if any feature descriptor attributes are supplied with this property.