Client side blueprint handler for digger
This is merged into $digger as the 'blueprints' property.
The blueprint format in digger is a very simple XML structure.
The elements are:
An example of the most basic blueprint with 1 field - 'name':
The top level blueprint element can have the following properties:
The name is how the blueprint will be referenced and can be any string. If there is no tag attribute then the name is used as the tag.
The tag will be assigned to the container created from the blueprint.
Here is a blueprint known as 'My Big Blueprint Title' but that will create a 'thing' container.
Here is a blueprint that uses the name for the tag:
This is invalid (because there is no tag - the name cannot have spaces):
The class attribute of the blueprint will be assigned to the new container:
The leaf attribute of the blueprint means that no children can be added to the container:
The children attribute controls what other blueprints can be added to this one.
The names are split by comma and only those blueprints are allowed as children.
Each blueprint has an array of fields that control what will appear on the form.
Each field has 2 core properties:
For example - if we wanted to edit the 'comments' property of a container and have a 'textarea' appear for it:
You can nest fieldnames with dots.
This example would create an 'address' object with 3 properties inside. The default type is 'text'.
You can have a different label from the fieldname:
There are a number of built-in fieldtypes:
Here is an example blueprint with 3 fields of different types:
A field can be a list of values - to turn a field into a list add list="true" to the XML:
Tabs group other fields or can display a single field.
To have a tab with some fields:
To have a tab that is a single field:
To have a tab that is a single list:
The radio and select types need an array of options to fill.
The simplest way is to add them to the field.
You can do this either with a csv string:
Or with nested option elements:
Another way to fill options is to load them from a digger query.
Here is an example of populating a select list with the countries from a warehouse:
For single page applications you can also include custom field types in the form of a template.
Digger fields use angular and so templates are in angular markup - the model and fieldname properties of the scope are used to write to the container.
Here is a custom radio button as an example template:
And here is a blueprint that uses that template:
Digger components enable you to a GitHub repository as a field type.
Here is an example of using the ace-editor as a field type:
Digger will download the component - build it and inject it into the field.