capire come progettare la nostra web application

Questo articolo non è una vera e propria guida, ma vuol essere una piccola premessa per orientarsi nella realizzazione di "web application" per joomla (o per qualsiasi altro CMS) con tutte quelle estensioni chiamate in gergo CCK che sarebbe poi l'acronimo di "Content Construction Kit" o "Kit per costruire contenuti".

Frequentando il forum di joomla.it, vedo spesso richieste tipo "vorrei un estensione per gestire un database", oppure "vorrei creare un catalogo personalizzato con i dati di un database che già posseggo", o ancora "vorrei importare il mio database su joomla".

Tutte richieste lecite e fattibili ma che debbono essere affrontate un poco dal punto di vista gestione e sicurezza, così spesso accade che ad applicazione creata succede che:

  • tutti possono vedere i dati, mentre volevamo farli vedere solo ad un certo gruppo di persone,
  • tutti possono modificare i dati, mentre volevamo farli modificare solo ad una, due, massimo 3 persone,
  • i dati personali dell'utente sono visualizzabili da tutti,
  • tutti possono creare, cancellare ed editare questi dati

Quindi di fatto anche se l'applicazione funziona, nel momento che la pubblicheremo sarà alla mercè di tutti e questo non è buono.

Quando progettiamo una applicazione, di fatto stiamo progettando anche il suo database, il contenitore che conterrà questi dati: immaginate una semplice applicazione che ci consenta di gestire i libri di una piccola biblioteca o semplicemente la merce di un negozio, ogni libro potrebbe essere censito inserendo un minimo di campi come;

  • un ID come chiave primaria
  • titolo
  • autore
  • editore

Se però vogliamo integrare funzioni che joomla già possiede dobbiamo aggiungere qualche campo supplementare.

La prima cosa che vorrei è quella di poter accedere all'applicazione dopo il login, questo mi garantirebbe un utilizzo privilegiato, potrei ad esempio decidere di far visualizzare i miei titoli solo a chi voglio io, ad uno dei gruppi standard di joomla come il "registered" oppure ad un gruppo creato per l'occasione.

Il fatto poi che "lego" l'applicazione al login mi da quegli strumenti che servono per gli inserimenti, le modifiche e le cancellazioni.

Poi potrebbe essere utile sapere la data di inserimento/creazione di un titolo e la sua successiva modifica, molto utile se ad esempio associamo il campo della modifica il nome dell'operatore che ha effettuato questa modifica.

Un altra possibile caratteristica potrebbe essere quella di pubblicare/sospendere un titolo, in un eventuale ricerca potrebbe fare comodo sapere quali titoli sono disponibili e quali no.

Vediamo adesso nel concreto quali sono i campi che occorrono oltre ai primi 4:

  • user_id
  • created
  • modified
  • state

Il primo campo "user_id" ci permetterà di creare quell'abbinamento utente di joomla/id del libro, questa informazione è necessaria per garantire i meccanismi di chi può vedere il record, chi lo può editare, chi lo può cancellare o chi lo può creare, infatti ogni utente che si è registrato al sito ha un suo "user_id" ed è di default inserito nel gruppo "registered", consentendoci ad esempio di far visualizzare i record/titoli a quel gruppo. Se poi l'utente appartiene ad un gruppo con un livello di credenziali superiore, come ad esempio il gruppo "editor", potremmo permettere agli appartenenti a questo gruppo di poter inserire nuovi record, editarli e cancellarli.

Naturalmente sarà possibile far visualizzare i dati anche alle persone non registrate se la logica di utilizzo lo prevede, quindi basterà "dire" all'applicazione, o meglio al CCK che la visualizzazione soltanto (e magari di certi dati) sarà libera per il gruppo "Guest".

Il campo "created" sarà quel campo che in automatico prenderà data ed ora della creazione del record, mentre il campo "modified" sarà quello dove verranno inserite la data e l'ora di eventuali successive modifiche apportate al record.

Infine il campo "state" sarà quello dove inserire uno "0" (zero) oppure un "1" (uno), dove "zero" sta per sospeso e "uno" per pubblicato.

Come abbiamo potuto notare a fronte di 4 semplici campi per la gestione di un libro o oggetto che sia, ne occorrono almeno altri 4 per gestire in maniera efficace ed efficiente la tabella e tutti i record contenuti in essa.

Occupatoci di questa fondamentale "pre-costruzione" della nostra web application, sarà necessario in qualche caso inserire qualche stringa di PHP al fine di poter interrogare il database in maniera adeguata, ad esempio inserendo una stringa per far modificare un record solo da chi lo ha generato, oppure inserendone una per filtrare una lista impaginando tutti quei libri inseriti in un intervallo di date, tutti quelli inseriti dall'operatore "Pippo" o dall'operatore "Topolino".

Ora in questo articolo abbiamo preso in considerazione solo quel "minimo sindacale" che c'è da sapere usando una sola tabella, ma vi assicuro che anche per piccole applicazioni come quella dell'esempio, un semplice catalogo per libri, c'è molto di più!

Un applicazione del genere, cosiderando questi dati:

  • un ID come chiave primaria
  • titolo
  • autore
  • editore
  • user_id
  • created
  • modified
  • state

dovrebbe avere una tabella per i soli autori ed una per gli editori in modo tale da eliminare dati ridondanti come autore ed editore, ma magari di questo ne parliamo la prossima volta in un articolo specifico alla progettazione di un database.

Se avete domande, registratevi e commentate. Se volete potete offrirmi un caffè cliccando nel pulsante sottostante, oppure cliccate su uno dei banner pubblicitari.

offrimi un caffè