Alpaca supports Connectors as a means for loading schema, options, view and data information from remote data sources. By default, Alpaca comes with a default connector that handles loading of data from public / unprotected HTTP/HTTPS URLs.

Connectors are used to load information based on what they receive in the following properties:

• schemaSource
• optionsSource
• dataSource
• viewSource

Information loaded from any of these sources is merged with information that is fed directly into Alpaca. This allows you to provide some of the information within code and load the rest of it via the Connector. An example is shown below.

You can implement your own Connector classes by extending the Alpaca.Connector class. This is shown in one of the examples below as well.

The Default Connector

The default connector supports the use of the following configuration properties to load remote files:

• dataSource
• schemaSource
• optionsSource
• viewSource

Here is an example where we load remote files into Alpaca:

• connector-custom-data.json
• connector-custom-schema.json
• connector-custom-options.json
• connector-custom-view.json

Merging Remote Data

Anything that is loaded via a connector is merged with whatever was passed into Alpaca. This lets you do things like instantiate Alpaca with a base configuration that might include default settings or inline functions while automatically merging dynamically configurable stuff that comes from a remote source.

Let's extend what we did in the previous example.

Here is an example where we merge the options to override the validation logic for the title field. We plug in a custom validator using an inline function. Since functions don't serialize via JSON over the wire, we provide this function implementation when we invoke Alpaca and then let the Connector sort out the options data retrieved over the wire. This options data is merged with our block below and the resulting options are used to render the form.

Connect to Cloud CMS

Alpaca comes with a cloudcms connector that lets you load form information and data directly from Cloud CMS. The Cloud CMS connector requires that you first load the Cloud CMS JavaScript Driver.

To use it, simply set the connector.id property to cloudcms and provide the following information to connect to your tenant:

• clientKey
• clientSecret
• username
• password
• application

You can get these bits by downloading your Developer API Keys.

The Cloud CMS Connector lets you load content type definitions (schema), forms (options) and nodes (data) seamlessly by referencing their QNames or Node IDs directly.

• schemaSource - the node ID or QName of the Cloud CMS content type definition
• optionSource - the node ID or form key of the Cloud CMS form
• dataSource - the node ID of the Cloud CMS JSON object holding your data

In the end, it ends up looking something like this:

Data Source loading with the Cloud CMS Connector

The Cloud CMS connector supports loading a data source array based on a Cloud CMS node query. A configuration is passed to the loader that indicates the query to be executed as well as an optional mapping to convert node structures into text and value pairs.

Here is an example where we query for custom:hero instances. The results will come back with text set to the node's title field and value set to the node's _doc identifier.

Data Source loading with the Cloud CMS Connector (Pagination and Mappings)

When using the Cloud CMS connector to load data source arrays, you may further specify pagination and text/value mappings between your node instances and the data source array.

Here is an example where we sort heroes by strength descending and paginate starting from record #20 in the result set and only getting back 10 heroes. We also adjust the mapping so that the key field maps to the data source array's value and fullName maps to the display text.

Custom Connector (using SSO Header)

You can implement your own custom connectors and use them by specifying the connector.id configuration option. Simply declare your connector and register it with the framework first.

Here is an example where we extend the default connector and set a custom SSO header for use in connecting to a backend server to load things:

Custom Connector