Overview
Pattern: Full autogeneration
Tutto il flusso applicativo (lista, edit, chart, ...) viene derivato dal modello dati via scaffolding del framework. Non scrivi codice frontend ne' codice server: descrivi l'oggetto, e le pagine sono immediatamente funzionanti, navigabili e collegate al menu.
Quando usarlo
- CRUD standard su entity tabellari, con relazioni 1-N e lookup gia' modellate.
- Demo, prototipi, MVP rapidi.
- Pannelli interni (admin, back-office) dove l'UX di default e' sufficiente.
- Casi in cui la velocita' di rilascio batte la personalizzazione visuale.
Architettura
Tre attori, una sola cosa che fai tu (scaffolding):
- Sviluppatore: lancia lo scaffolding sull'oggetto. Niente codice.
- Framework: produce metadata, espone le route, rende le pagine.
- Utente finale: naviga il menu, accede a list / edit / chart / spreadsheet auto-generati.
Cosa fai tu
Apri Amministrazione → Scaffolding. La pagina ha quattro selettori a cascata — connection,
database, table, column — piu' la casella Create Menu. Scegli la connessione, il database e la
tabella, lascia Create Menu attivo per avere subito la voce di menu, poi premi Scaffold Table
(Scaffold DB espone tutte le tabelle del database, Scaffold Columns riallinea le colonne di una
route gia' esistente).
Il framework crea automaticamente la metadata della pagina e di tutte le sue colonne con default sensati. La nuova route compare nel menu ed e' subito navigabile (#/<route>/list, ...). #/<route>/spreadsheet richiede una licenza che includa la feature spreadsheet: senza, la navigazione ricade sulla lista. Le dashboard non sono un archetype di route: si compongono con il Designer.
Re-eseguire lo scaffolding sullo stesso oggetto e' idempotente: aggiunge le novita' (es. nuove colonne) e preserva le personalizzazioni gia' applicate. Per il bootstrap dell'ambiente vedi Scaffolding iniziale.
Trade-off
| Pro | Contro |
|---|---|
| 0 codice da scrivere e mantenere | UX/layout fissati dagli archetype standard |
| Modifiche del modello sono live (no rebuild) | Personalizzazioni profonde richiedono uscire dal pattern |
| CRUD + filtri + paging + sort + export gratis | Performance ottimale fino a dataset medi (paging server-side e row-virtualization nel list-grid mitiga) |
| Permessi e audit centralizzati | Logiche di business specifiche vanno modellate come callback nei metadata o lato backend |
Esempi vivi nel WuicTest
- Cities autogen → apre
/cities/list(archetype default). Cartella sorgente:wwwroot/src/app/component/examples/pattern-1/1a-cities-autogen/. Apri demo. - Customers spreadsheet autogen → apre
/customers/spreadsheet(slug + archetype diverso). Cartella sorgente:wwwroot/src/app/component/examples/pattern-1/1b-customers-spreadsheet-autogen/. Apri demo.
Vedi anche
- Pattern 2 — Framework data + Custom component: vuoi tenere il data layer ma scrivere l'UI a mano.
- Pattern 3 — Framework component + Custom data: vuoi tenere l'UX standard ma scrivere il backend.
- Pattern 4 — Full custom: pure Angular + backend tuo, niente componenti ne' data layer del framework.
- Pattern 5 — Framework component + Framework data (manual mount): stessa data source + stessi widget del Pattern 1 ma monti tu il template Angular (controllo fine su layout e handling eventi).
- Designer & Workflow: personalizzare archetype/dashboard senza uscire dal pattern.
Screenshot
