> For the complete documentation index, see [llms.txt](https://docs.madrix.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.madrix.dev/hands-on-tutorials/5.-using-editor-mode.md).

# 5. Using Editor Mode

Use the **Editor Mode** for “surgical” adjustments to what the AI generated. Use the **AI Chat** for larger changes, with multiple screens and rules.

{% hint style="info" %}
If you want the complete reference (field types, events and structure), also see [**Editor Mode**](/documentation/editor-mode.md).
{% endhint %}

### Prerequisites

* You have edit permission on the project.
* Your app opens in **Preview**.

### Backend (final example)

Example goal: a **Task Manager** module with entity **Task**, common fields, relationship and status rule.

{% stepper %}
{% step %}

### 1) Adjust the module and menus

In the Editor, open **Modules** and edit (or create) a module:

* **Module name:** `Tasks`
* **Icon:** choose one that makes the card easy to identify.
* **Display Name Translations:**
  * `pt-BR`: `Tasks`

Create a menu inside the module:

* **Name:** `My tasks`
* **URL Path:** `/tasks`

{% hint style="warning" %}
Avoid changing the **URL Path** later. This breaks links and bookmarks.
{% endhint %}

**Expected result:** the module card appears on the Home. The menu navigates.
{% endstep %}

{% step %}

### 2) Create/adjust the component (entity)

Create a **Component**:

* **Name (lowercase):** `task`
* **Module:** `Tasks`
* **Display Name Translations:**
  * `pt-BR`: `Task`

When saving, use these options (when they appear):

* **Create frontend files:** yes (if you want scaffolded screens)
* **Create menu automatically:** optional (if you already created the menu manually)

**Expected result:** the component exists and already has UI structure (if checked).
{% endstep %}

{% step %}

### 3) Model fields (with ready examples)

Inside `task`, create the fields below:

* `title`
  * **Type:** `String`
  * **Required:** yes
* `description`
  * **Type:** `Text`
* `status`
  * **Type:** `Picklist`
  * **Options:** `New | In Progress | Review | Completed`
  * **Required:** yes
* `priority`
  * **Type:** `Picklist`
  * **Options:** `Low | Medium | High`
* `dueDate`
  * **Type:** `Date`
* `assignedTo`
  * **Type:** `User`
* `attachments`
  * **Type:** `Attachments`

Quick tip:

* If the list becomes “tight”, adjust the **Grid Width** per field.

**Expected result:** the Task form has all fields. The list shows the main ones.
{% endstep %}

{% step %}

### 4) Add a (1-N) relationship with Project

Create a second component:

* **Name:** `project`
* Minimum fields:
  * `name` (`String`, required, unique)

Now go back to `task` and create a field:

* `project`
  * **Type:** `Component`
  * **Related component:** `project`
  * **Cardinality:** 1 (a task belongs to a project)
  * **Display Field:** `name`

{% hint style="danger" %}
Only check `deleteCascade` if you accept deleting data in bulk.
{% endhint %}

**Expected result:** in the Task form, you select a Project.
{% endstep %}

{% step %}

### 5) Create a reusable query (optional but useful)

In `task`, create a **Query** called `Overdue`:

* Filter: `dueDate` less than today
* And `status` not equal to `Completed`

**Expected result:** you reuse this filter in lists and reports.
{% endstep %}

{% step %}

### 6) Business rule via Script (no “code” in the frontend)

Example rule: **do not allow status regression**.

Implement as a script in the component event `task`:

* Recommended event: **Before Update**
* Validation:
  * Allow only progression: `New → In Progress → Review → Completed`
  * Block any regression
* Clear error message:
  * “Status rollback is not allowed.”

Test in Preview:

* Create a task in `New`
* Advance to `In Progress`
* Try to go back to `New` and validate the block

**Expected result:** the rule works in the backend. It applies to UI and API.
{% endstep %}
{% endstepper %}

### Frontend (generated scaffold)

The scaffold only exists if you checked **Create frontend files** when saving the component.

#### What you get (summary)

* Base app routes.
* Pages protected by module.
* Forms and lists generated per component.
* Base theme and styles.

<details>

<summary>Where your module screens are usually located</summary>

Look for a structure like:

* `pages/protected/`
  * `{module}/` (e.g.: `tasks/`)
    * list, create and edit screens

</details>

#### What to edit vs what to avoid

Edit safely:

* Module pages (screens).
* UI components of your app.
* Theme (colors, typography).

Avoid editing:

* Files marked as **locked** (managed by the platform).

#### Validation checklist (Preview)

* [ ] Module card appears on the Home.
* [ ] Menu opens the listing.
* [ ] Create/edit Task works.
* [ ] Picklists have the correct options.
* [ ] Relationship with Project selects and saves.
* [ ] Status rule blocks regression.

{% hint style="info" %}
If the goal is to change only theme and texts, this is usually faster in **Project Settings**.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.madrix.dev/hands-on-tutorials/5.-using-editor-mode.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.