Conceptos esenciales

Antes de tocar cualquier botón, merece la pena fijar media docena de ideas. Todo lo demás en la plataforma — cada menú, cada panel, cada decisión que vas a tomar — se apoya en estos conceptos. Esta página los define una vez, con calma; los capítulos siguientes asumen que los conoces.

#La app — la unidad de todo

Una app es una aplicación completa y autocontenida: sus pantallas, modelo de datos, APIs, scripts, informes, ajustes y usuarios viven juntos y viajan juntos. Cada app tiene:

Propiedad	Qué es
Nombre	Cómo aparece la app en la lista y en el espacio de trabajo. Ej.: Gestión de Clientes.
Slug	La forma corta del nombre, derivada automáticamente, que entra en las direcciones. Ej.: gestao-clientes.
Icono	El símbolo de la app en la barra lateral y en la lista.
Descripción	Una frase libre, visible en la cabecera del árbol de la app.

Ser autocontenida tiene dos consecuencias prácticas:

• Una app puede exportarse como un archivo .keplinapp e importarse en otra instalación — se lo lleva todo consigo.
• Eliminar una app elimina su mundo (diseño, datos, archivos) sin tocar las otras apps ni las bases de datos externas a las que se conectaba.

#Pantallas — las páginas de la aplicación

Una pantalla es una página de la app construida, diseñada en un editor visual: arrastras widgets (tablas, formularios, gráficos, calendarios, …) a un canvas, los conectas a datos y defines qué pasa con cada clic. Cada pantalla tiene una ruta — el camino en la dirección de la app — y puede recibir parámetros (por ejemplo, el número del cliente a mostrar en una ficha).

Tres tipos de pantalla merecen nombre propio:

• Pantallas normales — las que creas y organizas libremente en el árbol.
• Pantallas de sistema — existen en todas las apps desde el primer segundo: Login, Recuperar contraseña y Registro. Editas su aspecto en el mismo editor, pero la ruta y el acceso son fijos.
• Pantallas públicas — servidas sin sesión iniciada, para páginas que cualquier persona puede ver. Solo pueden leer datos de APIs marcadas como públicas.

El pegamento entre pantallas es la Navegación: el menú de la app (barra superior o lateral), con elementos, submenús y atajos, diseñado en su propio editor.

#El modelo de datos

El modelo de datos es el mapa de las entidades de la app — tablas, campos, relaciones y enums — construido sobre las fuentes de datos (las bases de datos a las que la app se conecta). Importas las tablas que interesan al modelo, les das nombres amigables, y a partir de ahí el resto de la plataforma habla el idioma del modelo: las APIs de tabla generan operaciones completas a partir de él, las pantallas eligen campos por el nombre amigable, los enums alimentan listas de opciones.

El punto esencial: el modelo describe, no duplica. Los datos siguen viviendo en las bases de datos; el modelo es la capa que los hace utilizables por las pantallas y las APIs sin escribir la misma lógica dos veces.

#Versiones — trabajar sin miedo

Cada app tiene versiones, y la primera se llama siempre main. Una versión es una copia completa del diseño y de los datos de la app en ese momento — crear la versión «2.0» a partir de la main te da una rama donde puedes tocarlo todo sin afectar a lo que se está usando.

Lo que importa retener:

• La versión de trabajo es tuya. Cada persona elige en qué versión está trabajando; cambiar de versión no cambia la versión de nadie más.
• Las versiones no comparten datos. Una versión nueva nace con los datos copiados del origen; a partir de ahí, cada una sigue su vida.
• Cada versión tiene historial. Todas las grabaciones quedan registradas, con dos formas de volver atrás: Restaurar la app a este estado (devuelve todo a un momento) y Revertir este cambio (deshace una grabación concreta). Ninguna reescribe la historia — deshacer es siempre un paso nuevo en el registro.
• Puedes traer elementos entre versiones — una pantalla terminada en la «2.0» puede traerse a la main sin traer el resto.

#Publicación — qué versión sirve cada dirección

Publicar no es un botón de «poner en marcha» — es una asociación: cada dirección (host) sirve UNA versión de la app. En la sección Publicación de los ajustes de la app asocias un host (ej.: crm.empresa.com) a una versión; quien visite esa dirección ve esa versión, y solo esa.

Mientras no publiques ningún host, la app responde igualmente — en la dirección interna /app/<slug> (ej.: /app/gestao-clientes), con la versión de trabajo. Es el sitio natural para experimentar durante la construcción.

#Dos poblaciones de usuarios

Hay dos formas de estar en Keplin, con cuentas separadas y puertas separadas:

	Quien construye	Quien usa
Entra por	La página de entrada de la plataforma	La dirección de la app publicada (o /app/<slug>)
Ve	El espacio de trabajo: árbol, editores, versiones	Las pantallas de la app construida — y nada más
Cuenta gestionada en	Usuarios (menú global, administradores)	Usuarios de la app, en los ajustes de cada app
Perfiles	admin (todo, en todas las apps) y developer (solo las apps asignadas)	Los que definas en los Permisos de la app

Los usuarios de la app ni saben que Keplin existe: el login, el registro y la recuperación de contraseña que ellos ven son las pantallas de sistema de la app, con el tema y el idioma de la app. Esa separación se repite en todo — y por eso los ajustes de cada app (tema, traducciones, cuentas, permisos) viajan con ella cuando la exportas.