Conceitos essenciais
Os cinco conceitos que sustentam tudo no Keplin — apps, ecrãs, modelo de dados, versões e publicação — e as duas populações de utilizadores.
Antes de tocar em qualquer botão, vale a pena fixar meia dúzia de ideias. Tudo o resto na plataforma — cada menu, cada painel, cada decisão que vais tomar — assenta nestes conceitos. Esta página define-os uma vez, com calma; os capítulos seguintes assumem que os conheces.
A app — a unidade de tudo
Uma app é uma aplicação completa e auto-contida: os ecrãs, o modelo de dados, as APIs, os scripts, os relatórios, as definições e os utilizadores dela vivem juntos e viajam juntos. Cada app tem:
| Propriedade | O que é |
|---|---|
| Nome | Como a app aparece na lista e no espaço de trabalho. Ex.: Gestão de Clientes. |
| Slug | A forma curta do nome, derivada automaticamente, que entra nos endereços. Ex.: gestao-clientes. |
| Ícone | O símbolo da app na barra lateral e na lista. |
| Descrição | Uma frase livre, visível no cabeçalho da árvore da app. |
Ser auto-contida tem duas consequências práticas:
- Uma app pode ser exportada como um ficheiro
.keplinappe importada noutra instalação — leva tudo consigo. - Apagar uma app apaga o mundo dela (desenho, dados, ficheiros) sem tocar nas outras apps nem nas bases de dados externas a que se ligava.
Nota
A lista de apps que vês na barra lateral não é igual para toda a gente: cada conta só vê as apps a que tem acesso. Fora dessas, a app não aparece na lista nem abre por link.
Ecrãs — as páginas da aplicação
Um ecrã é uma página da app construída, desenhada num editor visual: arrastas widgets (tabelas, formulários, gráficos, calendários, …) para um canvas, ligas-los a dados e defines o que acontece a cada clique. Cada ecrã tem uma rota — o caminho no endereço da app — e pode receber parâmetros (por exemplo, o número do cliente a mostrar numa ficha).
Três tipos de ecrã merecem nome próprio:
- Ecrãs normais — os que crias e organizas livremente na árvore.
- Ecrãs de sistema — existem em todas as apps desde o primeiro segundo: Login, Recuperar palavra-passe e Registo. Editas o aspecto deles no mesmo editor, mas a rota e o acesso são fixos.
- Ecrãs públicos — servidos sem sessão iniciada, para páginas que qualquer pessoa pode ver. Só conseguem ler dados de APIs marcadas como públicas.
A cola entre ecrãs é a Navegação: o menu da app (barra superior ou lateral), com itens, submenus e atalhos, desenhado no seu próprio editor.
O modelo de dados
O modelo de dados é o mapa das entidades da app — tabelas, campos, relações e enums — construído sobre as fontes de dados (as bases de dados a que a app se liga). Importas as tabelas que interessam para o modelo, dás-lhes nomes amigáveis, e a partir daí o resto da plataforma fala a língua do modelo: as APIs de tabela geram operações completas a partir dele, os ecrãs escolhem campos pelo nome amigável, os enums alimentam listas de opções.
O ponto essencial: o modelo descreve, não duplica. Os dados continuam a viver nas bases de dados; o modelo é a camada que os torna utilizáveis pelos ecrãs e pelas APIs sem escrever a mesma lógica duas vezes.
Versões — trabalhar sem medo
Cada app tem versões, e a primeira chama-se sempre main. Uma versão é uma cópia completa do desenho e dos dados da app nesse momento — criar a versão «2.0» a partir da main dá-te um ramo onde podes mexer em tudo sem tocar no que está a ser usado.
O que importa reter:
- A versão de trabalho é tua. Cada pessoa escolhe em que versão está a trabalhar; trocar de versão não muda a versão de mais ninguém.
- As versões não partilham dados. Uma versão nova nasce com os dados copiados da origem; a partir daí, cada uma segue a sua vida.
- Cada versão tem histórico. Todas as gravações ficam registadas, com duas formas de voltar atrás: Repor a app neste estado (volta tudo a um momento) e Reverter esta alteração (desfaz uma gravação específica). Nenhuma reescreve a história — desfazer é sempre um passo novo no registo.
- Podes trazer elementos entre versões — um ecrã acabado na «2.0» pode ser trazido para a main sem trazer o resto.
Publicação — que versão serve cada endereço
Publicar não é um botão de «pôr no ar» — é uma associação: cada endereço
(host) serve UMA versão da app. Na secção Publicação das definições
da app associas um host (ex.: crm.empresa.com) a uma versão; quem visitar
esse endereço vê essa versão, e só essa.
Enquanto não publicares nenhum host, a app responde na mesma — no endereço
interno /app/<slug> (ex.: /app/gestao-clientes), com a versão de
trabalho. É o sítio natural para experimentar durante a construção.
Dica
Este modelo dá-te ambientes de graça: a main publicada no endereço de
produção, a «2.0» num endereço de testes, e a tua versão de trabalho em
/app/<slug> — três públicos, três versões, a mesma app.
Duas populações de utilizadores
Há duas formas de estar no Keplin, com contas separadas e portas separadas:
| Quem constrói | Quem usa | |
|---|---|---|
| Entra por | A página de entrada da plataforma | O endereço da app publicada (ou /app/<slug>) |
| Vê | O espaço de trabalho: árvore, editores, versões | Os ecrãs da app construída — e mais nada |
| Conta gerida em | Utilizadores (menu global, administradores) | Utilizadores da app, nas definições de cada app |
| Perfis | admin (tudo, em todas as apps) e developer (só as apps atribuídas) | Os que definires nas Permissões da app |
Os utilizadores da app nem sabem que o Keplin existe: o login, o registo e a recuperação de palavra-passe que eles vêem são os ecrãs de sistema da app, com o tema e o idioma da app. Essa separação repete-se em tudo — e é por isso que as definições de cada app (tema, traduções, contas, permissões) viajam com ela quando a exportas.
Nota
Ao longo desta documentação, «utilizador» sem mais qualificação refere-se a quem constrói. Quando falamos de quem usa a app construída, dizemos sempre utilizadores da app.