Definição

No Nerdify, o modelo representa o centro da regra de negócio. Ele organiza, em uma estrutura declarativa, tudo que um recurso da aplicação pode fazer, exibir, se relacionar ou responder. Não estamos falando de interface — estamos falando de comportamento e regra de negócio.

Porém, por mais que o Nerdify não gera a interface a partir do modelo, os templates usam a definição do modelo como base para o frontend interpretar e montar automaticamente as views. Essa arquitetura cria um elo poderoso entre backend e frontend, onde o modelo descreve a lógica, os templates entendem essa lógica e constroem a resposta em JSON com todas as informações necessárias para o frontend gerar as páginas dinamicamente.

🗭 A conexão entre modelo e template acontece através dos controladores dinâmicos do Nerdify, que interpretam a requisição, aplicam convenções de rota e estrutura, e constroem a resposta com base nos blocos do modelo, organizando os dados para que o template monte a estrutura necessária para o frontend — tudo sem precisar escrever uma linha de HTML.

🧠 O modelo como ponto central da lógica

Ao incluir Nerdify::Model em uma classe Ruby e definir o ORM utilizado (hoje suportando apenas mongoid), você transforma a classe em um modelo do Nerdify:

include Nerdify::Model
orm :mongoid

⚠️ O Nerdify foi projetado para ser compatível com múltiplos ORMs no futuro, mas hoje exclusivamente o Mongoid está ativo, pois é o único que possui a a conexão implementada para o modelo funcionar com o banco de dados, no caso o MongoDB.

Esse modelo não se limita a descrever campos de banco de dados. Ele define:

As ações possíveis (como criar, editar, excluir)
Os relacionamentos
A estrutura dos campos e agrupamentos
Os filtros
As listas e visualizações

Tudo isso de forma organizada, facilitando:

A implementação das regras de negócio no backend
A interpretação dos dados pelos templates, que montam a interface automaticamente

💫 Blocos do modelo

Cada modelo é composto por blocos e métodos que representam diferentes dimensões do comportamento da regra de negócio:

🔐 `acts_as_user`

Permite que o modelo atue como usuário autenticável.
É utilizado em autenticação JWT via devise_token_auth, permitindo login, tokens e permissões.

acts_as_user *options

Esse é o bloco pode ser utilizado, por exemplo, no modelo User.

🛠️ `actions`

Define as ações RESTful (como new, edit, show, destroy) e personalizadas, com regras de visibilidade, permissões, e definições de qual layout o frontend deve utiliar para chamar a ação no modelo, entre outras configurações possíveis.

🔗 `associations`

Relacionamentos com outros modelos (has_many, belongs_to, has_and_belongs_to_many, etc).
Esses relacionamentos alimentam o backend com dados vinculados e são reconhecidos automaticamente nos forms, filtros e templates.

🧾 `fieldsets`

Definem a estrutura lógica da entrada e visualização de dados, com agrupamentos hierárquicos.

Cada fieldset pode conter:

fields: campos básicos (nome, email, etc)
components: blocos complementares de dados
embeds: estruturas de modelos embutidos
outros fieldsets: aninhamento hierárquico

O fieldset organiza a regra de negócio de forma clara para que os templates entendam como estruturar os formulários e páginas automaticamente.

🔍 `filters`

Declaram os filtros de consulta para o modelo.
Cada filtro:

Permite montar buscas estruturadas
Gera automaticamente índices no Mongoid para otimizar performance de consulta Cada bloco de filters pode conter:
add para adicionar um input de filtro. Caso utilize o mesmo nome de um field definido previamente, herda as opções de configuração do mesmo, sobrescrevendo apenas a que forem setadas diretamente como parametro do add.

📋 `lists`

Definem como coleções desse modelo pode ser apresentadas (ex: tabelas, cards, etc), com configurações que são usadas pelos templates para passar ao frontend. Podem incluir campos e componentes, além de opções de ação para clique no item da coleção.

Cada bloco de lists pode conter:

add para adicionar um field definido previamente com mesmo nome, herda as opções de configuração do mesmo, sobrescrevendo apenas a que forem setadas diretamente como parametro do add.
components: blocos complementares de dados

⚙️ Exemplo de estrutura de modelo

Abaixo, um exemplo simplificado de um modelo Customer:

class Customer
  include Nerdify::Model
  orm :mongoid

  acts_as_user# *options

  action :acion_name#, *options

  associations do
    has_many :children
    belongs_to :parent
  end

  fieldsets :name, *options do
    fieldset :informacoes_gerais do
      field :name, type: :text#, *optioins
      field :birthdate, type: :date#, *options
    end

    fieldset :endereco do
      embed :address#, *options
    end
  end

  filters :name do
    add :birthdate
  end

  list :list_name, type: :table do
    add :name
    add :brithdate
  end
end

🛠️ Geração automática via CLI

O CLI do Nerdify permite gerar um modelo com todos esses blocos automaticamente preenchidos com comentários e exemplos:

nerdify generate model Customer --layout page

Esse comando cria:

A estrutura básica do modelo
Blocos actions, fieldsets, filters, lists, etc.
Comentários explicando o que colocar em cada lugar

📁 Por convenção do Rails (e consequentemente do Nerdify), os modelos devem ficar na pasta app/models.
O roteamento automático, os carregamentos dinâmicos e a estrutura de convenções dependem disso para funcionar corretamente.

🔗 Conexão entre lógica e interface

Reforçando: ao estruturar seus modelos com os blocos do Nerdify, você não está criando a interface.
Você está declarando a lógica de negócio de forma estruturada e interpretável. Para gerar as páginas no frontend, ainda será necessário passar pelos controladores que devem usar templates para determinar como estruturar a página usando como referência informações dos blocos definidos no modelo.

Os controladores dinâmicos do Nerdify conectam:

O modelo (lógica de backend)
Com o template (estrutura de frontend)
Para gerar JSON com a estrutura das páginas para o frontend monta-las automáticamente.

Em outras palavras: o Nerdify transforma a lógica do backend em dados organizados, e o frontend interpreta essa estrutura e monta a tela — sem necessidade de HTML, CSS ou JS manual.

🧠 O modelo como ponto central da lógica​

💫 Blocos do modelo​

🔐 acts_as_user​

🛠️ actions​

🔗 associations​

🧾 fieldsets​

🔍 filters​

📋 lists​

⚙️ Exemplo de estrutura de modelo​

🛠️ Geração automática via CLI​

🔗 Conexão entre lógica e interface​