An object property definition defines a single piece of data and its type. A property can also define minimum and maximum values, a default, or “special value” and other data-related behaviors. The specific data-related behaviors will vary depending on the data type of the property. The properties of an object give that object its characteristics. A property is the equivalent to a variable in other development platforms or languages.
When designing and developing an object’s properties, the properties should represent all of the values to be retrieved from the back end system plus those that may be necessary for client-side processing. Examples of this latter group include state-related values or other data that will not be retrieved from or updated to the back end, but that may be needed on the Client.
When data typing your properties, the primary driving factor in the decision should be the data type of the back end value the property is to store. However, it is not a requirement that the data type of the object property match the data type of the back end value. The Agentry Server will always attempt to convert data retrieved from the back end system to the data type of the property definition. Therefore, if a value stored as one data type in the back end system, such as an integer, needs to be stored and used as a different data type on the Client, such as a string, it is completely valid to create a string property. Be aware, however, that when data types differ in this manner that the rules of safe data conversion still apply. For example the conversion of a string to an integer is not considered type safe and can result in undesirable behavior.
When designing an object’s properties you must always include a “key property” that uniquely identifies each instance of the object. Any property definition of almost any data type within the object can be designated as the key property. In practice the key property should be the value that uniquely identifies the business entity in the back end system. Examples include the work order number or customer ID, which would be values that would be defined to be the key property. The object definition contains an attribute that specifies which of its properties is the key property. Therefore the property must first be defined, and the object then edited to specify which property is the key property.
The key property is then how instances of the object will be uniquely identified by the Agentry Client and the Agentry Server. Only one object instance with a specific key property value can exist within a given collection property. Furthermore, the key property is also how the Server identifies the object instances within the collection for synchronization purposes. If a collection property is created for an object definition, that object must have a selected key property. The Agentry Editor will not allow the collection definition to be created for an object that does not have a key property.
The name attribute of the property should be set to the same name as it is identified by in the back end system. This plays an important part in synchronization, as the Server will look to how data values are identified in the back end system and match those values with properties of the same name. In addition to this requirement, following the back end names also makes future maintenance of the application easier.
If it is not possible to name a property to match the back end value, the identity of that value should be aliased in some manner during retrieval. For example the AS (SELECT Field1 AS Name1) keyword in SQL allows for this. In a Java back end the data returned can be renamed using the return data structure that stores the data for objects, as the members of that structure can be named to match the property definitions, with their values assigned to variables with different names from the back end system.