Modelagem com doctypes

DocType é o núcleo do desenvolvimento em NEO. É ele que define estrutura de dados, experiência base do formulário, permissões e grande parte da integração entre backend e front-end.

O que um DocType define

Um DocType pode definir:

• campos;

• layout;

• naming;

• permissões;

• workflow documental;

• comportamento via controller;

• visualizações do Desk;

• integração com reports e APIs.

Tipos de DocType

Tipo	Uso
Padrão	Registro persistido em tabela própria
Child Table	Estrutura dependente do pai
Single	Configuração global com instância única
Tree	Estrutura hierárquica
Submittable	Documento com draft, submit e cancel
Virtual DocType	Estrutura lógica sem tabela padrão

Antes de criar campos

Vale responder:

1. qual entidade de negócio está sendo representada;

2. qual é a identidade natural do registro;

3. que dados são digitados e quais são derivados;

4. se o documento terá submit ou workflow;

5. se haverá tabela filha;

6. como isso aparecerá no Desk e no portal.

Tipos de campo e impacto no front-end

Tipo de campo	Efeito no front-end
Data / Date	Widgets e validações específicas
Select	Opções controladas
Check	Interação booleana simples
Link	Busca remota e navegação
Table	Grade embutida no formulário
Attach	Upload de arquivo
Read Only	Campo informativo ou calculado

Modelar bem é também modelar a experiência padrão da UI.

Layout e ergonomia

Boas práticas:

• colocar status e identificadores no topo;

• separar dados cadastrais e operacionais;

• usar seções e colunas;

• evitar excesso de obrigatórios;

• deixar derivados como somente leitura.

Child Tables

Child Tables funcionam bem para:

• linhas de documento;

• composições;

• anexos estruturados;

• regras por item.

No front-end, elas mudam bastante a experiência do usuário porque a edição passa a acontecer dentro do formulário pai.

Single, Tree e casos especiais

Single

Ideal para configurações globais.

Tree

Bom para hierarquias como categorias ou estrutura organizacional.

Virtual DocType

Útil quando o dado vem de outra fonte ou lógica agregada, exigindo backend mais customizado.

Impacto da modelagem nas APIs e no Desk

Uma modelagem boa facilita:

• REST padrão;

• neo.db.get_list;

• reports;

• listas do Desk;

• portal e website;

• impressões e dashboards.

Checklist de revisão

• o nome representa o domínio;

• os obrigatórios são realmente necessários;

• o layout ajuda o usuário;

• as permissões foram pensadas;

• o modelo atende Desk, API e relatórios;

• o impacto no front-end é aceitável.