Formulate Docs Terms / Concepts
- INPUT VIEW
- A VIEW used for entering new SUBMISSIONs into the system.
- DASHBOARD VIEW
- A VIEW for displaying the history of submissions to a particular form (note, that is submissions to a FORM, not a single VIEW).
- UPDATE VIEW
- A VIEW for updating the values of an existing SUBMISSION
- ACCOUNT
- All Users and all Views belong to an ACCOUNT. Primarily this is for implementing access restrictions. A USER may only access VIEWs which are in their ACCOUNT.
- ALIAS
- ACCOUNTs and VIEWs have a property called Alias which is the name of the account or view converted into an alphanumeric, camel case string. So, for example, the view "My First View" would have an alias of "myFirstView"
- USER
- A simple user definition describing a username and password as well as an account. All users are associated with a single ACCOUNT and may or may not be ADMINs.
- ADMIN
- ADMIN users have the ability to edit FORMs and create new VIEWs
- FORM
- A FORM is a collection of FIELDS representing every piece of information you may want to collect.
Note that FORMs are not tied to an account.- FIELD
- A FIELD represents one piece of information. This could be directly related to an HTML field like "Product Type" or "Part Number but it may also represent other data, for example, "Submission Status" or "Currently Assigned To".
Note that since FORMs are not tied to an ACCOUNT a single FIELD may be part of more than one VIEW.- OPTION
- OPTIONs make up the list of possible values for an HTML field. For example, given a <select> (dropdown) control, the possible selections would be considered OPTIONs
- FORM OPTION
- A FORM OPTION is an option which cannot be removed or altered by a user with EDIT VIEW permission, only ADMIN users can modify FORM OPTIONs. The purpose of this is to allow other users to configure VIEWs but to ensure that some options are always present.
- VIEW
- A VIEW is a subset of FIELDS from one particular FORM. Let's say that you have a FORM with these three FIELDs: "Product Owner", "Product Type", and "Part Number". Now, say that most of your users will be filling out all three fields when submitting a request. However, perhaps you have another set of users which is only allowed to submit one "Product Type". They would not need to see the "Product Type" field as it's not applicable to them. In this case you could create two VIEWs one of which would include all three fields while the other included only "Product Owner" and "Part Number".
- USER VIEW
- A USER VIEW is a database object which indicates that a given user has access to a given view. ADMIN users may always access every VIEW in their ACCOUNT but non-admin users must have each VIEW assigned to them. This assignment creates a USER VIEW.
- VIEW FIELD
- A VIEW FIELD is associated with a particular VIEW and a particular FIELD. Using the example in the description of VIEW, the first set of users would have 3 VIEW FIELDS while the second set would have only 2. VIEW FIELDs have properties which relate to an HTML form field like "field label" and "is required". The second set of users from the example would have two VIEW FIELDs, "Product Owner" and "Part Number". Let's say that these users have a different term for "Part Number", they call it "Product ID". You can assign the label "Product ID" to the VIEW FIELD representing "Part Number" so that the user sees the text "Product ID" but the value for this field in their submission will still be tied to the "Part Number" FORM FIELD. In this way you can have several VIEW FIELDs with different names and properties (one is required, another is not, etc) which will all tie their values back to a single FORM FIELD so the submissions from multiple VIEWs may be viewed together in a common DASHBOARD VIEW.
- FIELD TYPE
- Each VIEW FIELD has a FIELD TYPE which determines the type of HTML control that will be displayed in the INPUT VIEW and UPDATE VIEW. Examples are "text field", "drop down", "checkbox group", etc.
- VIEW OPTION
- A VIEW OPTION is an OPTION which may be modified or removed by any user with EDIT VIEW permission.
- TRIGGER
- A TRIGGER represents a client-side event which is fired when the user modifies a VIEW FIELD say by selecting an option from a drop down or checking a checkbox. TRIGGERs modify the values of other VIEW FIELDs on the page.
- TRIGGER TYPE
- There are 3 TRIGGER TYPEs.
- VALUE TRIGGER - sets the value of a field (selects an option in a dropdown, marks a checkbox, etc.)
- VALUESET TRIGGER - replaces the OPTIONS of a VIEW FIELD with a given set. An example would be selecting Honda in one dropdown and having a second dropdown automatically populated with Accord, Camry, Civic, etc.
- URL VALUESET - same as a VALUESET but the options, rather than being statically defined, are retrieved from a URL
- TRIGGER VALUE
- In the case of a VALUE TRIGGER, the value to which the target field will be set. In the case of a VALUESET, the options which are to replace those of the target field.
- TRIGGER CONDITION
- Conditions which must be met in order for a trigger to be applied.
- VISIBILITY CONDITION
- Conditions which must be met for a VIEW FIELD to be shown (if it is hidden).
- EVENT
- An event is triggered in response to a submission. Events update submission values. An example would be automatically changing the "status" of an submission to "updated" when the submission is updated.
- EVENT CONDITION
- Conditions which must be met for an event to be triggered.
- NOTIFICATION
- An email which will be sent out when either a form is submitted or when a submission is updated.
- FILTER
- Adds a button to the DASHBOARD VIEW which, when selected, will filter the submissions displayed.
- SUBMISSION
- A submission to a VIEW
URL Format: /formulate/form/[account alias]/[view alias]
Input View
The INPUT VIEW is what you would most easily think of as a "standard web form". It consists of empty field inputs each representing a VIEW FIELD in the VIEW configuration.
The screenshot to the right shows an INPUT VIEW with one field of each possible type. Note that the datepicker looks like a regular textfield until it is selected.
Here is a brief description of each type of field.MORE STUFF GOES HERE
- Text Field
- A basic text field
- Datepicker
- A popup datepicker
- Drop Down
- A single-selection, drop-down list
- Checkbox Group
- A set of checkboxes, each with a separate option, which can be independently selected. Note that the checkboxes are not individual FIELDs but instead the entire group of checkboxes is a single VIEW FIELD.
- Radio Buttons
- A group of radio buttons only one of which may be selected.
- Textarea
- A multi-row text area
- Upload
- An asynchronous, multi-file upload control. Unlike the standard HTML upload field, files are uploaded asynchronously meaning that as soon as the user selects a file it begins to upload without the user being required to click submit. The file upload progress will be shown while the file uploads and the upload action may be canceled at any time. Also note that, unlike the standard control, the user is able to upload more than one file.
URL Format: /formulate/dashboard/[account alias]/[view alias]
Dashboard View
Submission Rows
Each row in the table represents a submission object. The values displayed are the current submission values. That is, if a submission is updated these values will reflect the updated value rather than the initial value of the field.
Clicking on the table header will sort the table by that column. Clicking again will sort in the opposite direction. An arrow will be displayed indicating the sort column and direction.
Submission fields may have multiple values in the case of checkbox or upload input controls. In this case, the values will be displayed in a list. Upload fields values link to the uploaded file.
Filter Buttons
In the top left corner are displayed Filter Toggle buttons. These buttons will filter the list of submissions by specific criteria. See the editor section for more information about filters.
Search
The search field in the top right corner will filter the submissions based upon a search term. The search will be performed against all fields in the submission.
Pagination
By default, 10 records at a time will be displayed. The label below the pagination will display the total number of records.
History
Clicking the History button opens a popup showing the history of the selected submission. Each submissions event is displayed as a row with the final column containing the user who submitted the values and the date the submission was made.
Edit Button
If the form has both the Dashboard View and the Update View enabled, the edit button will open an Update View for the selected submission in a popup.
URL Format: /formulate/update/[account alias]/[view alias]/[submission id]
Update View
TEXT HEREURL Format: /formulate/manager/[account alias]
Manager View - User
User Account Editor
Views List
Manager View - Admin
Account Users Editor
Views List
Form Editor
URL Format: /formulate/edit/[account alias]/[view alias]
Editor View
Toolbar Links
View Options
View Fields Editor
Notifications Editor
Events Editor
Filters Editor
View Users Editor
Form Editor
User Access
TEXT HEREStyling and Scripting Views
TEXT HEREJSON Submissions [Web Services]
TEXT HERECredits, Libraries & Licenses
Formulate makes use of the following Java Libraries:All of the above libraries are available under the Apache 2.0 license - http://www.apache.org/licenses/LICENSE-2.0
- Stripes 1.5.6 - http://www.stripesframework.com
- ORM Lite 4.4.0 - http://www.ormlite.com
- Jackson 1.9.5 - http://jackson.codehaus.org/
- GSON - http://code.google.com/p/google-gson/
- Apache Velocity 1.7 - http://velocity.apache.org/
- Apache log4j 1.2 - http://logging.apache.org/log4j/1.2/
- Apache Commons - beanutils, collections, fileupload, io, lang, logging, validator
The browser interface for Formulate is built using the Google Angular JS framework - http://angularjs.org
and the Twitter Bootstrap CSS framework - http://twitter.github.com/bootstrap
Formulate was written by Daniel Hinds-Bond - http://007design.com