> For the complete documentation index, see [llms.txt](https://quasarframework-brasil.gitbook.io/skeleton-quasar/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://quasarframework-brasil.gitbook.io/skeleton-quasar/english/como-utilizar/schema.md).

# Schema

When defining a`schema`we will inform which fields will be used, which events these fields will handle, the components that will be used in the forms for each of the fields and how the table that carries the data related to the entity that the`schema`represents will be displayed. In addition to the fields, the available actions (buttons) and component behaviors will also be mapped.

Briefly with the`schemes`, all`forms` and `tables` that will be rendered will be created. The purpose of a`schema`is to create the necessary artifacts so that the components of creating forms and tables have enough data to work with.

To manage the fields we have two methods:

* `addField`: adds a new field to the`schema`;
* `getField`: select a field that is already part of the `schema`to be manipulated;

To manipulate table-related properties:

* `fieldTableWidth`: defines the width of the field in the table;
* `fieldTableShow`: defines whether the field will be visible or not in the table;
* `fieldTableWhere`: determines whether the field will be displayed in the table side search;
* `fieldTableFilter`: defines whether the field will be used as a fixed filter at the top of the table;
* `fieldTableRequired`: specifies whether it is possible to hide the field;
* `fieldTableName`: allows changing the name of the property being accessed in the list;
* `fieldTableAlign`: configure the alignment in the table;
* `fieldTableSortable`: determines whether it is possible to apply sorting through that field;
* `fieldTableFormat`: function that will be used to format column values before displaying on the line;
* `fieldTableOrder`: it allows configuring the field ordering between the table fields;

To determine the components that will be used by the fields we have:

* `fieldIsInput`: determines that the field will use a standard text component;
* `fieldIsNumber`: determines that the field will use a numeric type input component;
* `fieldIsPassword`: determines that the field will use an input component of type password with hashes in the characters;
* `fieldIsEmail`: determines that the field will use an e-mail input component, according to the validations created for it;
* `fieldIsText`: determines that the field will use a textarea component similar to a notepad;
* `fieldIsCheckbox`: determines that the field will use a checkbox component;
* `fieldIsRadio`: determines that the field will use a radio button component, passing the values through a parameter;
* `fieldIsSelect`: ;
* `fieldIsSelectRemote`: ;
* `fieldIsSelectRemoteMultiple`: ;
* `fieldIsToggle`: ;
* `fieldIsDate`: determines that the field will use a Data component, the settings must be passed via an attribute;
* `fieldIsDatetime`: determines that the field will use a Date and Time component, the settings must be passed via attribute;
* `fieldIsInputPlan`: ;
* `fieldIsArray`: determines that the field will use a customized CRUD component, its functionality is the same as that of a crud;
* `fieldIsCurrency`: ;
* `fieldIsButton`: ;

There are still some macros available to configure some fields:

* `fieldAsPrimaryKey`: ;
* `fieldAsZip`: ;
* `fieldAsPhone`: ;
* `fieldAsCell`: ;
* `fieldAsMasked`: ;

To manipulate properties related to the form we have the following methods:

* `fieldFormWidth`: ;
* `fieldFormDisabled`: ;
* `fieldFormHeight`: ;
* `fieldFormHidden`: ;
* `fieldFormName`: ;
* `fieldFormAutofocus`: ;
* `fieldFormDefaultValue`: ;
* `fieldFormErrorHide`: ;
* `fieldFormErrorShow`: ;
* `fieldFormUpperCase`: ;
* `fieldFormPlaceholder`: ;
* `fieldFormOrder`: ;

To deal with validation we have the following methods:

* `validationAdd`: ;
* `validationAs`: ;
* `validationRequired`: ;
* `validationRequiredIf`: ;
* `validationRequiredWhen`: ;
* `validationRequiredUnless`: ;
* `validationMinLength`: ;
* `validationMaxLength`: ;
* `validationMinValue`: ;
* `validationMaxValue`: ;
* `validationBetween`: ;
* `validationAlpha`: ;
* `validationAlphaNum`: ;
* `validationNumeric`: ;
* `validationInteger`: ;
* `validationDecimal`: ;
* `validationEmail`: ;
* `validationIpAddress`: ;
* `validationMacAddress`: ;
* `validationPassword`: ;
* `validationSameAs`: ;
* `validationUrl`: ;
* `validationOr`: ;
* `validationAnd`: ;
* `validationNot`: ;
* `validationWithParams`: ;
* `validationClear`: ;
* `validationRemove`: ;


---

# 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:

```
GET https://quasarframework-brasil.gitbook.io/skeleton-quasar/english/como-utilizar/schema.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.