Adaptive Objects

Adaptive Object Model

Adaptive Objects are similar to many Object paradigms you may have been introduced to in a programming or data structure lessons. They contain data in a structured way, just as key/values, dictionaries or hashes encapsulate data in other popular languages. With Adaptive Objects, the object that contains data is described by another object, called its Object Type. The keys and values on the Adaptive Object are referred to as Adaptive Properties and the definitions of those properties, which are contained within the Object Type definition, are called Property Types. These definitions provide us with useful metadata that can be used for data validation, user interface representation, authorization controls, and even data transformation and generation. The following diagram illustrates these relationships, and is commonly referred to as the Type Square Pattern:

An Adaptive Object may have one or more Adaptive Properties. Likewise, an Object Type may have one or more Property Types. Moreover, an Object Type describes one or more Adaptive Object instances, just as an Adaptive Property Type may describe one or more Adaptive Properties. Let's examine these objects, in detail, in order to get a better sense of how they are related.

Let's define an Adaptive Object of interest with something that is familiar. As a Person, I have some properties that describe me. For example, I have a First Name, a Last Name and an Age.

{
    "First Name": "Kevin",
    "Last Name": "Smith",
    "Age": 40
}

Other people also have names and ages. Therefore, we can describe a Person using an Object Type. This Object Type contains Property Types, declared under a special name, propertyTypes, for "First Name", "Last Name" and "Age". In this example, you will find "First Name", "Last Name" and "Age" all have Property Type values of structured objects that contain information about them. "First Name" and "Last Name" have a dataType of string and Age is described as an integer. Both have additional description properties that provide additional:

{
    "propertyTypes": {
        "First Name": {
            "dataType": "string",
            "description" "This is a person's first name."
        },
        "Last Name": {
            "dataType": "string",
            "description": "This is a person's last name."
        },
        "Age": {
            "dataType": "integer",
            "description": "This is a person's age, in years."
        }
    }
}

This very simple example also demonstrates an aspect of Adaptive Objects that may not seem obvious on the surface. "Object Type" Person is also an Adaptive Object, and "propertyTypes" here is also an Adaptive Property, whose value is an object containing "First Name", "Last Name" and "Age". It's only when we establish the Object Type relationship between these two that we apply semantic meaning to this object. In fact, the Person Object Type in this example also has an Object Type, called _AdaptiveObjectType_, which describes how an Adaptive Object Type is structured. Likewise, the object type _AdaptivePropertyType_, is used to describe how an Adaptive Property Type is structured. These two special objects are defined by Core as compiled object definitions. We can change the Person Object Type, because it's an object not defined to core, but we cannot change "_AdaptiveObjectType_" or "_AdaptivePropertyType_" without recompiling Adaptive Framework.

Object Types and Property Types

In the previous section, we demonstrated how an Object Type and its Property Types can describe an instance of an Object. We also introduced the idea that Object Types and Property Types are also objects, themselves, described by "_AdaptiveObjectType_" and "_AdaptivePropertyType_" and defined as compiled-in objects to Adaptive Framework Core. Let's first look at what makes an Adaptive Property Type, using the example from the previous section. The Adaptive Property "First Name" had a Property Type definition that included a property called "dataType". The dataType property is an important one that we will get into more details later. Here is a more complete list of properties that define a Property Type:

Object Meta

We've now covered Object Types and Property Types and how useful they are in describing an object or collection of objects by extracting their "metadata" and storing it in a common place. In addition to Object Types and Property Types, all objects contain some additional metadata that is useful for Adaptive Framework Core, Adaptors, and even clients. As you may have already guessed, these too are documented and stored in a special Object Type called _AdaptiveMeta_, which looks like the following:

Absolute Object Paths

Object Paths

Every Adaptive Object in Adaptive Framework is uniquely identified by an Object Path of the form:

/<adaptorId>/<objectTypeId>/<objectId>

An objectId is the unique object identifier of the entity, optionally followed by a slash-separated representation of embedded properties.

/<adaptorId</<objectType</objectId
/<adaptorId</<objectType</objectId/propertyName
/<adaptorId</<objectType</objectId/propertyNameA/propertyNameB

If the property value is a list, a property name can be followed with a zero based integer index enclosed in square brackets ([n]).

/<adaptorId>/<objectTypeId>/<objectId>/<propertyNameA>[<index>]
/<adaptorId>/<objectTypeId>/<objectId>/<propertyNameA>[<index>]/<property name>
/<adaptorId>/<objectTypeId>/<objectId>/<propertyNameA>/<propertyNameB>[<index>]
/<adaptorId>/<objectTypeId>/<objectId>/<propertyNameA>[<index>]/<propertyNameB>[<index>]

Relative Adaptive Object Path

An Object URI can contain a path as defined above, a full URI with scheme, or a relative path. If a path is relative, it must be resolved relative to a supplied path.

If a relative path begins with a /, its structure is the same as an absolute path with * used in place of <adaptorId>, <objectTypeId>, and each shashed part of <objectId> to use the corresponding value from the supplied path. The <objectId> can also be ** to indicate that the entire <objectId> including all slash-separated properties should be used.

If a relative path does not begin with a /, the <adaptorId> and <objectTypeId> from the supplied path will be used and the relative path will be used as the /<objectId>. The character sequence /* can be used as a corresponding part from the supplied path's /<objectId>.

The following are some examples of relative references using the given path: /adaptorId/objectTypeId/objectId/prop1/prop2:

Embedded Objects

Some Adaptive Objects may have properties that also contain objects. We call these objects Embedded Objects. The following object illustrates an example of an Embedded Object, referenced by the Embedding Property address:

{
    "name": "John Doe",
    "address": {
        "street": "123 Main St.",
        "city": "Anytown",
        "state": "CA",
        "zip": "12345"
    }
}

Inheritance

Adaptive Objects also allow for inheritance, so that Adaptive Objects can borrow properties from other Adaptive Objects. This is done through a special "meta" property called parentPaths:

{
    "_meta_": {
        "parentPaths": [
            "/registry/_AdaptiveObjectType_/Person"
        ]
    },
    "employeeId": "12345",
    "officeAddress": {
        "street": "123 Main St.",
        "city": "Anytown",
        "state": "CA",
        "zip": "12345"
    }
}

When observing an Adaptive Object that contains a parent path, the Object Option composite can be specified to resolve the parent and include their properties in the returned object. The following is an example of the same object with the composite option specified:

{    
    "first": "John",
    "last": "Doe",
    "age": 42,
    "employeeId": "12345",
    "officeAddress": {
        "street": "123 Main St.",
        "city": "Anytown",
        "state": "CA",
        "zip": "12345"
    }
}

Object Options

Adaptive Objects can be provided with Object Options that influence how an object should be displayed, including what metadata should be provided, or how Adaptive Property values should be interpreted or represented. The options that one uses is up to the application or client that is consuming or providing the objects. For example, a UI may require a lot of metadata to understand how to render properties on a screen, while a programmatic parser may request property values to be encoded in a way that's convenient for the client. Below is a table of the object options that are available.