Concetti essenziali

Prima di toccare qualsiasi pulsante, vale la pena fissare una mezza dozzina di idee. Tutto il resto della piattaforma — ogni menu, ogni pannello, ogni decisione che prenderai — poggia su questi concetti. Questa pagina li definisce una volta, con calma; i capitoli successivi danno per scontato che tu li conosca.

#L'app — l'unità di tutto

Un'app è un'applicazione completa e autocontenuta: le sue schermate, il modello dei dati, le API, gli script, i report, le impostazioni e gli utenti vivono insieme e viaggiano insieme. Ogni app ha:

Proprietà	Che cos'è
Nome	Come l'app appare nell'elenco e nello spazio di lavoro. Es.: Gestione Clienti.
Slug	La forma breve del nome, derivata automaticamente, che entra negli indirizzi. Es.: gestao-clientes.
Icona	Il simbolo dell'app nella barra laterale e nell'elenco.
Descrizione	Una frase libera, visibile nell'intestazione dell'albero dell'app.

Essere autocontenuta ha due conseguenze pratiche:

• Un'app può essere esportata come file .keplinapp e importata in un'altra installazione — porta tutto con sé.
• Eliminare un'app elimina il suo mondo (progetto, dati, file) senza toccare le altre app né i database esterni a cui era collegata.

#Schermate — le pagine dell'applicazione

Una schermata è una pagina dell'app costruita, disegnata in un editor visuale: trascini widget (tabelle, moduli, grafici, calendari, …) su un canvas, li colleghi ai dati e definisci che cosa succede a ogni clic. Ogni schermata ha un percorso — il cammino nell'indirizzo dell'app — e può ricevere parametri (per esempio, il numero del cliente da mostrare in una scheda).

Tre tipi di schermata meritano un nome proprio:

• Schermate normali — quelle che crei e organizzi liberamente nell'albero.
• Schermate di sistema — esistono in tutte le app fin dal primo secondo: Login, Recupero password e Registrazione. Ne modifichi l'aspetto nello stesso editor, ma il percorso e l'accesso sono fissi.
• Schermate pubbliche — servite senza sessione avviata, per pagine che chiunque può vedere. Riescono a leggere dati solo da API contrassegnate come pubbliche.

La colla fra le schermate è la Navigazione: il menu dell'app (barra superiore o laterale), con voci, sottomenu e scorciatoie, disegnato nel suo proprio editor.

#Il modello dei dati

Il modello dei dati è la mappa delle entità dell'app — tabelle, campi, relazioni ed enum — costruita sulle origini dati (i database a cui l'app si collega). Importi nel modello le tabelle che interessano, dai loro nomi amichevoli, e da lì in poi il resto della piattaforma parla la lingua del modello: le API di tabella generano operazioni complete a partire da esso, le schermate scelgono i campi per nome amichevole, gli enum alimentano gli elenchi di opzioni.

Il punto essenziale: il modello descrive, non duplica. I dati continuano a vivere nei database; il modello è lo strato che li rende utilizzabili dalle schermate e dalle API senza scrivere due volte la stessa logica.

#Versioni — lavorare senza paura

Ogni app ha versioni, e la prima si chiama sempre main. Una versione è una copia completa del progetto e dei dati dell'app in quel momento — creare la versione «2.0» a partire da main ti dà un ramo dove puoi mettere le mani su tutto senza toccare ciò che è in uso.

Quello che conta ricordare:

• La versione di lavoro è tua. Ognuno sceglie su quale versione sta lavorando; cambiare versione non cambia la versione di nessun altro.
• Le versioni non condividono i dati. Una versione nuova nasce con i dati copiati dall'origine; da lì in poi, ognuna segue la propria vita.
• Ogni versione ha una cronologia. Tutti i salvataggi restano registrati, con due modi di tornare indietro: Ripristina l'app a questo stato (riporta tutto a un momento) e Annulla questa modifica (disfa un salvataggio specifico). Nessuno dei due riscrive la storia — disfare è sempre un passo nuovo nel registro.
• Puoi portare elementi da una versione all'altra — una schermata finita nella «2.0» può essere portata in main senza portare il resto.

#Pubblicazione — quale versione serve ogni indirizzo

Pubblicare non è un pulsante «metti online» — è un'associazione: ogni indirizzo (host) serve UNA versione dell'app. Nella sezione Pubblicazione delle impostazioni dell'app associ un host (es.: crm.azienda.com) a una versione; chi visita quell'indirizzo vede quella versione, e solo quella.

Finché non pubblichi nessun host, l'app risponde lo stesso — all'indirizzo interno /app/<slug> (es.: /app/gestao-clientes), con la versione di lavoro. È il posto naturale per sperimentare durante la costruzione.

#Due popolazioni di utenti

Ci sono due modi di stare in Keplin, con account separati e porte separate:

	Chi costruisce	Chi usa
Entra da	La pagina di accesso della piattaforma	L'indirizzo dell'app pubblicata (o /app/<slug>)
Vede	Lo spazio di lavoro: albero, editor, versioni	Le schermate dell'app costruita — e nient'altro
Account gestito in	Utenti (menu globale, amministratori)	Utenti dell'app, nelle impostazioni di ogni app
Profili	admin (tutto, in tutte le app) e developer (solo le app assegnate)	Quelli che definisci nelle Autorizzazioni dell'app

Gli utenti dell'app non sanno nemmeno che Keplin esista: il login, la registrazione e il recupero della password che vedono sono le schermate di sistema dell'app, con il tema e la lingua dell'app. Questa separazione si ripete ovunque — ed è per questo che le impostazioni di ogni app (tema, traduzioni, account, autorizzazioni) viaggiano con lei quando la esporti.