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
Connectors are used to load information based on what they receive in the following properties:
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 supports the use of the following configuration properties to load remote files:
Here is an example where we load remote files into Alpaca:
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
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.
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
To use it, simply set the
connector.id property to
cloudcms and provide the following
information to connect to your tenant:
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.
In the end, it ends up looking something like this:
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
Here is an example where we query for
custom:hero instances. The results will come back with
to the node's
title field and
value set to the node's
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
fullName maps to the display
You can implement your own custom connectors and use them by specifying the
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: