\r\n

51Degrees Pipeline Documentation  4.1Newer Version 4.4

Search

Documentation

• Features
• Flexible Accessors

Flexible Accessors

Introduction

The Pipeline API has been designed to be easy-to-use, adding IDE auto-complete support where possible. However, one of our key design goals was to allow new properties to be added without the API software needing to be updated. These goals are often in conflict and lead to the creation of several possible mechanisms to retrieve property values.

Detail

The precise nature of the available accessors depend on the language being used but we have aimed to support the following use-cases:

1. Accessing properties without any 'magic strings' and with IDE auto-complete support.
2. Accessing a property that has been returned by the data source but that did not exist when the current version of the flow element was built.
3. Accessing a property without first accessing the associated aspect data.

C# Java Node.js PHP Python

Select a tab to view language specific information on the internal data structure.

In .NET, IDE auto-complete support is dependent on having a specific interface/type with defined properties. This is supported by allowing the aspect data type and associated interface to be extended for each engine. Flow data can then then return this specific type/interface. For example, the 51Degrees device detection engines use the IDeviceData interface to define all the properties that are available. After flow data has been processed, you can request the IDeviceData from it:

var deviceData = flowdata.Get<IDeviceData>();

If you have an instance of the element that you want to get data for, this can also be used to get the data populated by that instance:

var deviceData = flowdata.getFromElement(deviceDetectionEngine);

After you have the specific element data instance, the individual properties can be accessed as normal using strongly typed property accessors. For example, accessing the IsMobile property looks like this:

flowdata.Get<IDeviceData>().IsMobile;

Where a new property is present in the data source that did not exist when the code was compiled, a string-based accessor can be used instead. As long as you know the string name of the property you can access it, even if it does not exist in the interface. The downside is that this is not strongly-typed so you will need to deal with casting. For example, accessing the IsMobile property in this way can be done like this:

flowdata.Get<IDeviceData>()["IsMobile"];

The GetAs variation can be used if you know the type of the property:

flowdata.Get<IDeviceData>().GetAs<AspectPropertyValue<bool>>("IsMobile");

In addition, a shortcut can be used to access the property without specifying the associated flow element/engine at all. However, this has the downside that you will need to know the type of the property you are accessing. For example, the IsMobile property can be accessed like this:

flowdata.GetAs<AspectPropertyValue<bool>>("IsMobile");

In Java, IDE auto-complete support is dependent on having a specific interface/type with defined properties. This is supported by allowing the aspect data interface to be extended for each engine. Flow data can then then return this specific interface. For example, the 51Degrees device detection engines use the DeviceData interface to define all the properties that are available. After flow data has been processed, you can request the DeviceData from it:

DeviceData deviceData = flowdata.get(DeviceData.class);

If you have an instance of the element that you want to get data for, this can also be used to get the data populated by that instance:

DeviceData deviceData = flowdata.getFromElement(deviceDetectionEngine);

After you have the specific element data instance, the individual properties can be accessed as normal using strongly typed property getters. For example, accessing the IsMobile property looks like this:

flowdata.get(DeviceData.class).getIsMobile();

Where a new property is present in the data source that did not exist when the code was compiled, a string-based accessor can be used instead. As long as you know the string name of the property you can access it, even if it does not exist in the interface. The downside is that this is not strongly-typed so you will need to deal with casting. For example, accessing the IsMobile property in this way can be done like this:

flowdata.get(DeviceData.class).get("IsMobile");

In addition, a shortcut can be used to access the property without specifying the associated flow element/engine at all. However, this has the downside that you will need to know the type of the property you are accessing. For example, the IsMobile property can be accessed like this:

flowdata.getAs("IsMobile", AspectPropertyValue.class, Boolean.class);

In Node, auto-complete support is not feasible so you need to know the name of the element and property that you're accessing. For example, if you are using the 51Degrees device detection engine then after the flow data has been processed, you can request the device data from it:

let deviceData = flowdata.device;

If you have an instance of the element that you want to get data for, this can also be used to get the data populated by that instance without having to know the associated name:

let deviceData = flowdata.getFromElement(deviceDetectionEngine);

After you have the specific element data instance, the individual properties can be accessed using normal property accessors. Node's weakly typed nature means that the scenario where a new property is available in the data source is not a problem. Wherever it's come from, you just need to know the name of the property you want to retrieve. For example, accessing the IsMobile property looks like this:

flowdata.device.ismobile;

In PHP, auto-complete support is not feasible so you need to know the name of the element and property that you're accessing. For example, if you are using the 51Degrees device detection engine then after the flow data has been processed, you can request the device data from it:

$deviceData = flowdata->device;

If you have an instance of the element that you want to get data for, this can also be used to get the data populated by that instance without having to know the associated name:

$deviceData = $flowdata->getFromElement(deviceDetectionEngine);

After you have the specific element data instance, the individual properties can be accessed using normal property accessors. PHP's weakly typed nature means that the scenario where a new property is available in the data source is not a problem. Wherever it's come from, you just need to know the name of the property you want to retrieve. For example, accessing the IsMobile property looks like this:

$flowdata->device->ismobile;

In python, auto-complete support is not feasible so you need to know the name of the element and property that you're accessing. For example, if you are using the 51Degrees device detection engine then after the flow data has been processed, you can request the device data from it:

deviceData = flowdata.device;

If you have an instance of the element that you want to get data for, this can also be used to get the data populated by that instance without having to know the associated name:

deviceData = flowdata.get_from_element(deviceDetectionEngine);

After you have the specific element data instance, the individual properties can be accessed using normal property accessors. Python's weakly typed nature means that the scenario where a new property is available in the data source is not a problem. Wherever it's come from, you just need to know the name of the property you want to retrieve. For example, accessing the IsMobile property looks like this:

flowdata.device.ismobile;

Generated by doxygen 1.8.15