Estrutura de apps e sites

A estrutura física do projeto sugere onde cada responsabilidade deve morar. No NEO, isso ajuda a separar backend, metadados, website e assets do front-end.

Estrutura típica de um app

apps/biblioteca/
├── README.md
├── pyproject.toml
└── biblioteca/
    ├── hooks.py
    ├── modules.txt
    ├── patches.txt
    ├── public/
    │   ├── css/
    │   ├── js/
    │   └── images/
    ├── templates/
    │   ├── includes/
    │   └── pages/
    ├── www/
    └── biblioteca/
        └── doctype/

Papéis dos arquivos principais

Arquivo / pasta	Função
hooks.py	Registro de pontos de extensão
modules.txt	Lista de módulos do app
patches.txt	Sequência de patches
public/	Assets públicos
templates/	Templates Jinja reutilizáveis
www/	Rotas web publicadas
doctype/	Modelos e comportamento dos documentos

App x Site

App

Pacote reutilizável, versionável e instalável.

Site

Instância em execução com dados, configuração e arquivos próprios.

Um mesmo app pode existir em múltiplos sites.

Onde vivem artefatos de front-end

O front-end do NEO aparece em vários pontos da estrutura:

• public/ para JS, CSS e imagens;

• templates/ para website e portal;

• www/ para páginas públicas;

• arquivos JS específicos de DocType;

• arquivos de pages e listas.

Estratégia prática para organizar assets

public/
├── js/
│   ├── forms/
│   ├── lists/
│   ├── pages/
│   └── shared/
├── css/
│   ├── app/
│   └── pages/
└── images/

O que não misturar

• regra crítica apenas em JS;

• website e Desk sem fronteira clara;

• assets globais para resolver caso local;

• customizações não versionadas.

Sinal de estrutura madura

Uma base NEO está bem organizada quando:

• o app pode ser instalado do zero;

• os assets são reproduzíveis;

• o time localiza rapidamente backend, Desk e website;

• a experiência da UI não depende de configuração manual escondida.