> For the complete documentation index, see [llms.txt](https://readme.directual.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://readme.directual.com/web-pages/components/legacy-components/form.md).

# Form (legacy)

{% hint style="warning" %}
This component is outdated. Use advanced [multi-step form](/web-pages/components/multistep-form.md) instead
{% endhint %}

## Component **Overview**

The Form component serves several purposes:

* Collecting data
* [Editing objects](/web-pages/components/legacy-components/form.md#editing-existing-objects)
* Interacting with the user through online [result processing](/web-pages/components/legacy-components/form.md#online-result-processing).

## Component Settings Sections

* [**General**](/web-pages/components/legacy-components/form.md#general-form-settings)**:** Settings like the header, description, button text
* [**Fields**](/web-pages/components/legacy-components/form.md#fields-settings)**:** Inputs for each form field
* [**Result**](/web-pages/components/legacy-components/form.md#online-result-processing)**:** On-line submission processing.

## General Form Settings

* [API-endpoint](/api-integrations/api-endpoints-security-layer.md). Defines the fields available for writing in the form
* Form Title
* Form Description (you can use [Markdown](/data/data-types/markdown-cheatsheet.md) here)
* Submit Button Text (`Submit` by default)
* Labels or Placeholders. Switches the view of inputs: field names can be displayed *above the field* or as a *placeholder.*
* Form max width in pixels
* Default http-request parameters.

## Fields Settings

Each field, which is available for writing (POST-requesting) or reading (GET-requesting) in an [API-endpoint](/api-integrations/api-endpoints-security-layer.md), has a specific [data type](/data/data-types.md). You can configure the form input field and set the default value according to the field type.

### Sections

You can display sections as visible sections or as invisible groups, which can be particularly useful for conditional sections.

### Conditional Sections

The visibility of a section can depend on the user's choice of field values above (or on existing objects fields in the case of [object editing](#editing-existing-objects)). If you add more than one conditional, you can choose either the AND or OR operator to join your conditionals.

If you want to check if a field is empty, enter the `null` value. Conversely, use `isNotNull`, if you want the field to have any value other than empty.

![In this example, Section 2 is visible only if the user choses value "bug" for the field {{feature\_type}}](/files/-M_uE8CSoLM2rCG0mXMy)

### Link and ArrayLink Quick Search Option

When the dropdown for `link`/`arrayLInk` field is ON (it is OFF by default), objects from the linked structure can be displayed as options in dropdown selects. The [visible name](/data/data-structures.md#structure-visible-name) of the linked will be displayed, and if there is no such, name, the `id` field will be displayed instead. 

To make this feature work, you need to create an API endpoint for it. You can also add [different filters ](/api-integrations/api-endpoints-security-layer.md)to that endpoint, such as "objects connected with the current user."

{% hint style="info" %}
The maximum quantity of options in the dropdown is limited to 1000.
{% endhint %}

### Hidden Fields

If you marked a field as hidden (which is possible for *string* and *link* fields), their values will be obtained from the URL query parameters. 

It should look like this:

`yourapp.directual.app/FormPage?fieldOne=value&fieldTwo=1984`

{% hint style="warning" %}
Query parameters must start with a '`?'` and be separated by '`&'.`
{% endhint %}

In the submitted object, you will receive:

fieldOne = `value`

fieldTwo = `1984`

## Personalization

You can include a hidden field for User ID, which will be filled automatically if the user is logged in.

First, you need to have a field type of *link* to `WebUser` data structure available for posting in your API-endpoint.

Find the section **Personalization** in the **Fields settings**:

The user's ID will be posted in this field automatically If the user is logged in. If the user isn't logged in, the field will remain empty.

{% hint style="warning" %}
Remember, that you can configure your API-endpoint in a way that unauthorized user will not be able to submit the form.
{% endhint %}

## Editing Existing Objects

If you want to enable the option to edit existing objects in addition to creating new ones, you can turn on that option in the **Fields settings** section.

{% hint style="info" %}
Don't forget to include the `id` field in API-endpoint, making  it available both for writing and reading. Additionally, ensure all the fields you want to be fetched available for reading in API-endpoint settings. By default, the `id` field is included in the form, but it's hidden.
{% endhint %}

There are three ways to get the`id` of the object to edit:

1. From the query parameter: `@editObject=_id_` form the URL, where`_id_` represents the id of the object you would like to edit.
2. From URL parameters (this option matches with [subpages](/web-pages/setting-up-pages-layout/subpages-and-url-parameters.md))
3. Use the user's `id` as the `id` of the object to edit. This allows you to edit the App user (WebUser) object or any other object with such an ID. This option is commonly applied for profile settings.

## Result Resubmission

By default, after submitting the form, the user will see a success message and a button "Submit again". You can remove the button and disable resubmission, hide the button and redirect the user back to the form automatically after a few seconds. Also, you can edit the message (by using HTML).

## Online Result Processing

Submitted object can be processed in a [synchronous scenario](/scenarios/synchronic-scenarios-1.md), and then the result is to be displayed to the user. There three fields of the object for interpreting the result of object processing:

* **Result: success/fail**. A *Boolean* field. If the field is `true`, the Success block is displayed. If that field is `false`, the error block is displayed.
* **Result message title**. A String field. The title of the result block.
* **Result message text**. A String field (HTML usage is available here). The text of the result block.

![](/files/-MBdOyLB-fSRJnDMVRof)

{% hint style="warning" %}
Remember, that object is saved regardless of the result of synchronous processing. However, if the object does not meet the [validation rules](/api-integrations/api-endpoints-security-layer/advanced-techniques-for-get-requesting.md), it will not be saved. Validations are crucial to ensure that only data meeting specified criteria is stored.
{% endhint %}

{% hint style="info" %}
**Hint**: you can build an online calculator for your app using that form with a synchronous result processing.
{% endhint %}