User fields

Components can store strings in a library using user fields. These are associated with a component using a specific key. User fields are the easiest way for an application to share information among images, or to extend the components. The following components have user fields:

•	Configuration maps

•	Applications

•

Classes

•

Methods

•

Users

There are two types of user fields: inherited and local. Inherited user fields hold references to stored strings that they share with future editions of components. They are used when an associated object is relevant to each future edition of the component, such as with comment fields. Replacing the string does not affect the string associated with any other edition, but all future editions created from the changed edition share the new string. Local user fields (or description fields) are relevant only to the edition with which they are associated. New editions do not contain any local user fields.

Each time a user field is saved, the previous contents are lost. User fields are not versioned objects--you cannot back out of a change by retrieving the previous edition of the user field.

Use user fields sparingly. The underlying library implementation employs a write-once strategy. Monitor the growth of the library file to ensure that user field operations are not an issue.

For example, methods retrieve their comments from a library using the following:

self record inheritedUserFieldAt: 'comment'.

This retrieves the string associated with the key 'comment' in the receiver's record. The method inheritedUserFieldAt: answers an empty string if no such field is found.

To store this field, use the following:

self inheritedUserFieldAt: 'comment' put: aString.

To delete this field, use the following:

self deleteInheritedUserField: 'comment'.

To list the user field names of a component, use the following:

aComponent inheritedUserFieldNames.

Class definitions and class extensions also support inherited user field access. Because definitions and extensions are associated with a class in a particular application or subapplication, the methods are in Class and are slightly different, requiring the application as an extra parameter. The message pattern of the methods is the following:

inheritedUserFieldAt: aName in: anApplication

inheritedUserFieldAt: aName in: anApplication put: aString

deleteInheritedUserFieldAt: aName in: anApplication

inheritedUserFieldNamesIn: anApplication