Umbraco Forms field, prevalue source and workflow types are defined in C# and include one or more setting values.
These settings are completed by the editor when using the type on their form.
Each setting type can have it's own user interface. So a string can use a text box but a more complicated JSON structure can use a more appropriate user interface.
The user interface used for a particular setting is defined by the View
property:
The following setting types are available and are used for the field, prevalue source and workflow types that ship with the package.
Name | Description | Used in |
---|---|---|
All of the above setting types are used in one or more field, prevalue source and workflow types available with Umbraco Forms. For the less common ones, a usage has been indicated in the table.
The two exceptions are "TextWithFieldPicker" and "MultipleTextString". We do not use these two within the package, but we make them available for developers to use when creating their own types.
"TextWithFieldPicker" offers the option of text field entry or selection of a field from the form. This can be useful in workflows where you need to reference the value of a specific field.
"MultipleTextString" offers the option of creating multiple text field entries. This can be useful in workflows where you need to provide multiple text values.
To create a custom setting type you will need an AngularJS view and controller in the following location: /App_Plugins/MyPlugin/
.
Your plugin folder path must be outside of the /App_Plugins/UmbracoForms/
folder if you use a custom Angular controller and Package.manifest.
You then add the name of the view as the View
property on the Setting
attribute defined on the type.
Checkbox
Uses a single checkbox for entry
DocumentMapper
Used for selection of a documenttype
The "Save as Umbraco node" workflow
Dropdownlist
Used for selection from a list of options
EmailTemplatePicker
Used for selection of an email template
The "Send email with Razor template" workflow
FieldMapper
Used to map fields from a form to required aliases
The "Send to URL" workflow
File
Used for selection of a file
The "Send email with XSLT template" workflow
MultipleTextString
Uses multiple text boxes for entry
Not used in core types
NumericField
Uses numerical text box for entry
Password
Uses password text box for entry
PasswordNoAutocomplete
Uses password text box for entry (with autocomplete disabled)
Pickers.ContentWithXPath
Uses a content picker with the option for XPath entry
The "Save as Umbraco node" workflow
Pickers.Datatype
Uses a datatype picker
The "Umbraco prevalues" prevalue source
Pickers.DocumentType
Uses a document picker
The "Umbraco nodes" prevalue source
Range
Uses a slider for range input
The "reCAPTCHAv3" field type
RichText
Uses a rich text editor for input
The "Send email" workflows
StandardFieldMapper
Used to map system fields from a form to required aliases
The "Send to URL" workflow
Textarea
Used a multiline textbox for entry
Textfield
Used a single-line textbox for entry
TextfieldNoAutocomplete
Used a single-line textbox for entry (with autocomplete disabled)
TextWithFieldPicker
Used a single-line textbox/form field list for entry
Not used in core types
To add a new type, no matter if it's a workflow, field, data source, etc, there is a number of tasks to perform to connect to the Forms provider model. This chapter walks through each step and describes how each part works. This chapter will reference the creation of a workflow type. It is, however, the same process for all types.
Create a new class library project in Visual Studio add references to the Umbraco.Forms.Core.dll
(available via referencing the NuGet package). You might also need to reference Umbraco.Forms.Core.Providers.
The Forms API contains a collection of classes that can be registered at startup or in an Umbraco component. So to add a new type to Forms you inherit from the right class. In the sample below we use the class for the workflow type.
When you implement this class you get two methods added. One of them is Execute which performs the execution of the workflow and the other is a method which validates the workflow settings, we will get back to these settings later on.
Any dependencies required that are registered with the dependency injection container can be provided via the constructor.
Even though we have the class inheritance in place, we still need to add a bit of default information.
Even though we have the class inheritance in place, we still need to add a bit of default information. This information is added in the class's constructor like this:
All three are mandatory and the ID must be unique, otherwise the type might conflict with an existing one.
Now that we have a basic class setup, we would like to pass setting items to the type. So we can reuse the type on multiple items but with different settings. To add a setting to a type, we add a property to the class, and give it a specific attribute like this:
The Umbraco.Forms.Core.Attributes.Setting registers the property in Umbraco Forms and there will automatically be UI and storage generated for it. In the attribute, a name, description and the view to be rendered is defined.
With the attribute in place, the property value is set every time the class is instantiated by Umbraco Forms. This means you can use the property in your code like this:
For all types that use the provider model, settings work this way. By adding the Setting attribute Forms automatically registers the property in the UI and sets the value when the class is instantiated.
Each setting value is stored as a string with the user interface for generating the value defined via the View
property.
Umbraco Forms ships with setting types and you can also create your own.
The ValidateSettings()
method which can be found on all types supporting dynamic settings, is used for making sure the data entered by the user is valid and works with the type.
To register the type, ensure your web application project has a reference to the class library, either via a project or NuGet reference. Then add the following code into the startup pipeline. In this example, the registration is implemented as an extension method to IUmbracoBuilder
and should be called from Program.cs
:
An alternative approach is to use a composer, as per this example:
There are further convenience methods you can use for registering custom types. These are found in the namespace Umbraco.Forms.Core.Providers.Extensions
.
For example, instead of the following:
Your workflow can be registered using:
Or:
Existing items that are not required in a particular installation can be removed with:
Also look in the reference chapter for complete class implementations of workflows, fields and export types.
It is possible to override and inherit the original provider, be it a Field Type or Workflow etc. The only requirement when inheriting a fieldtype that you wish to override is to ensure you do not override/change the Id set for the provider, and make sure your class is public.
Here is an example of overriding the Textarea field aka Long Answer.
As discussed in the previous section, you must also register the extended field type within a composer. You also need to create the the backoffice field type view.
Composer:
Backoffice View:
Add a new HTML file as per the name of the field class (e.g. textareawithcount.html
) to \wwwroot\App_Plugins\umbracoforms\Backoffice\Common\FieldTypes\
within your project. For this example, we can copy the original textarea.html
file used by the standard 'Long Answer' field.
The AngularJS client-side files are shipped with Umbraco Forms as part of a Razor Class Library. So you won't find these files on disk when you install the package.
However if you do want to reference them you can view and extract them from the Umbraco.Forms.StaticAssets
NuGet package.