Gleam.br Wiki

ADR-0007: Motor de Layout de Site Dinâmico e Seções TOML | Wiki

Documentação de engenharia e especificações técnicas da Gleam-BR.

ADR-0007: Motor de Layout de Site Dinâmico e Seções TOML

Este documento especifica a decisão de design sobre o motor de layout dinâmico para páginas institucionais complexas do gerador de sites estáticos gbr_ssg, focado na orquestração de seções baseadas em dados declarados.

1. Contexto e Motivação

O gerador estático do Gleam-BR requer a renderização de páginas institucionais do tipo "Site" com conteúdo flexível e modular (Hero, Features, Perfis, etc.) em contraste ao conteúdo de texto corrido típico (Wiki/Blog). Para manter os princípios de *Sistemas Lúcidos* e *Arquitetura Sustentável*, a responsabilidade de gerenciar componentes visuais complexos deve ser abstraída e desacoplada do corpo markdown (que permanecerá enxuto ou não-utilizado nessas páginas). Dessa forma, empoderamos os redatores a construírem suas landing pages estritamente através do frontmatter declarativo.


2. Decisão Arquitetural

Optamos por utilizar **"Arrays de Tabelas" ([[sections]])** da especificação TOML no Frontmatter como estrutura de dados primária para a configuração e orquestração de seções visuais dinâmicas.

Premissas técnicas adotadas: 1. **O Componente Proxy (layout_site.gleam):** Este arquivo atuará unicamente como um iterador genérico. Ele inspecionará a chave "type" contida em cada entrada da matriz meta.sections (ex: hero, feature_grid) e delegará a renderização ao seu respectivo componente. 2. *Subcomponentes Desacoplados:* Cada "Seção" corresponderá a um arquivo Lustre isolado no diretório components/. Eles serão inteiramente responsáveis por traduzir os campos de dados do TOML em marcação HTML semântica com suporte Tailwind CSS. 3. *Conversão de Tipos e Segurança:* Os dados vindos do TOML passarão por extrações via tom e serão empacotados em um tipo nativo Option(List(Dict(String, String))). Essa flexibilização da tipagem, inerente à extração dinâmica de metadados, exigirá que a renderização do layout utilize mecanismos fail-soft (result.unwrap) em caso de omissão de chaves específicas.


3. Requisitos EARS

*Requisitos Ubíquos (Ubiquitous Requirements)* - *UBQ-01 (Decodificação de Seções Genéricas):* O decodificador TOML do core (ssg_core) DEVE extrair as matrizes dinâmicas definidas pela tabela [[sections]], convertendo seus pares chave-valor estritamente para o formato estrutural Option(List(Dict(String, String))) a ser anexado em PageMetadata. - *UBQ-02 (Tolerância a Falhas de Tipagem Dinâmica):* Todo componente da interface (ex. hero) DEVE resgatar chaves através da aplicação robusta de fallback padrão (result.unwrap(dict.get(section, "title"), "Sem Título")), garantindo que nenhuma ausência acidental de metadados rompa o ciclo de renderização completo do SSG.