Design pattern e best practices per la gestone di un form html general purpose. L'applicazione web ha una pagina che presenta un prodotto, dotato di vari campi editabili (es. descrizione, prezzo, ecc); Il server gestisce chiamate in GET che in POST. il candidato indichi la più via usabile per l'utente e più pulita a livello di implementazione.
La pagina viene richiamata all'indirizzo www.sitoweb.it\prodotti?id=XXXXX. L'utente è loggato con un cookie di sessione.
- Marco Rossi
Ma se scrivessi in un linguaggio comprensibile? Uno a piacere.
- khenzo Ленин
Ipotesi A: l'utente preme submit, la pagina fa una richiesta POST al server, salva i dati e fa la redirect alla pagina in GET. Dubbio: come passo i "messaggi di errore? in un "cookie di sessione"?
- Marco Rossi
Ipotesi B: La pagina fa una POST, salva i dati e renderizza il form aggiornato, con eventuali messaggi d'errore. Controindicazioni: ogni volta che l'utente fa F5 i dati vengono nuovamente postati.
- Marco Rossi
intanto se hai errori non salvi i dati :)
- Francesco Mosca
Non sono ammesse chiamate ajax, i controlli clientside non sono considerati.
- Marco Rossi
khenzo, sto cercando di imparare l'italiano, perdonami.
- Marco Rossi
POST → validazione ? dati validi: → salvataggio e redirect alla pagina di successo ; dati non validi → niente redirect. I messaggi di errore da mostrare li hai già senza bisogno di toccare la sessione. il problema del doppio post nel caso di back del browser lo risolvi solo con un token univoco (es. un token xsrf), ma del resto se l'utente fa back dopo aver visto una pagina di successo il problema potrebbe essere altrove.
- Francesco Mosca
In caso di dati validi faccio un redirect, ma se volessi portarmi un messaggio? Tempo fa dei colleghi lo portavano attraverso le variabili in "GET" ovvero quelle dopo il "?", ma mi sembra inopportuno.
- Marco Rossi
che messaggio? se i dati sono validi non hai messaggi se non quello di "bella storia, i tuoi dati erano ok"
- Francesco Mosca
se questo messaggio non è già compreso nella pagina di conferma, p.es. perché comunque dinamico, allora può aver senso utilizzare una variabile "flash", ovvero una variabile di sessione che viene pulita dopo il primo accesso: la scrivi nella richiesta che salva i dati, la mostri e la pulisci nella richiesta che mostra la conferma
- Francesco Mosca
Ok, se una variabile flash di sessione è considerata accettabile, procedo in questo modo :)
- Marco Rossi
ovviamente sarebbe del tutto overkill in questo caso, ma se ti trovi a porti frequentemente questo tipo di domande può avere molto senso dare uno sguardo alle pratiche comuni di uno o due framework del tuo linguaggio preferito (es. zend, symfony2 o yii per php, django per python etc.). quelle di cui abbiamo parlato sono più o meno comuni a tutti
- Francesco Mosca
non sarebbe affatto overkill ;)
- Marco Rossi
ah, avevo letto velocemente la premessa, pensavo che l'unico scopo dell'applicazione fosse gestire quel form :)
- Francesco Mosca
No, direi che è più imparare a realizzare decentemente applicazioni web, in generale :)
- Marco Rossi
Secondo me il problema è che ci sono proprio errori concettuali nella gestione della comunicazione client/server. Anche se non puoi usare javascript (poi, perchè?) puoi fare tutto sulla stessa pagina senza redirect e passaggio di valori in GET ma semplicemente con una corretta gestione del postback. Poi magari non ho capito io.
- khenzo Ленин
Se hai tempo e voglia, mi interessa conoscere la tua opinione, khenzo, se mi sono espresso male, ti prego dimmi dove, in modo che possa correggermi per il futuro.
- Marco Rossi
L'ultima frase del tuo post è troppo generica per delineare pratiche di usabilità e pulizia, come le definisci tu. Non si sa che deve fare questo form... General pourpose e design pattern sono antitetiche per me.
- khenzo Ленин
Intendevo un form dotato di campi generici es quantità, descrizione, prezzo, colore, commenti, ecc. Non intendevo esempi particolari di form (form di login/registrazione, form di upload file, creazione di un topic su forum, ecc)
- Marco Rossi
Insomma devi scrivere su un database. Non capisco la difficoltà. Il mio non è un pretesto per chissà quale polemica ma boh, se la gestione del codice è a tua discrezione tranne che per l'utilizzo di controlli client-side la risposta è nelle prime pagine di qualunque libro di un qualsiasi linguaggio di programmazione. Scusa ma per me è così.
- khenzo Ленин
in questo caso non ha particolarmente senso avere nella stessa pagina input e output (stiamo escludendo ajax e uso "pagina" nel senso classico del termine, quello client-side)
- Francesco Mosca
Volendo posso inviare i dati alla stessa pagina, a pagine diverse, volendo posso "postare" i dati con una chiamata GET, oppure fare caricare la pagina agli utenti sempre in POST, non ci sono regole fisse, ovvio, è facile leggere le prime pagine dei libri di programmazione web, a me premeva di sapere qual'è la soluzione più "raffinata" per migliorare il mio stile e non scrivere "spaghetti code" in un sito che vede tutto il mondo.
- Marco Rossi
"Un sito che vede tutto il mondo". Scusa ma non ce la faccio.
- khenzo Ленин
Cosa ho detto di male?
- Marco Rossi
Non è un sito da intranet aziendale.
- Marco Rossi
Come gestisci la sessione? I messaggi di errore dovrebbero stare in sessione, la sessione la gestisce il server. Per quanto riguarda l'uso di GET o POST, io preferisco quest'ultima. a meno che non devi pensare a future interfacce mobile con il server
- Vincio
per quanto riguarda design pattern, struttura il tutto in MVC
- Vincio
La sessione è attualmente gestita tramite cookie crittografati (con una semplice chiave simmetrica, non è richiesta particolare sicurezza) Pensavo di trasmettere i messaggi di errore in quel modo, evitando di salvare i dati in db o memcache. Non sono previste interfaccie mobili, ma mi hai dato una grande idea, svilupperemo presto l'applicazione Iphone / Android! Grazie Vincio!!!
- Marco Rossi