Piccole lotte quotidiane

Problem solving: storia di un form HTML

17 May 2006

Ciao a tutti
Attraverso questo articolo vi parlerò del mio approccio al problem-solving in una applicazione informatica, utilizzando un esempio a scopo didattico (il quale è stato risolto grazie all’apporto fondamentale di Vittorio B.) ma applicando un metodo di lavoro universale, che ho fatto mio da tempo, e che spero possa aiutarvi a migliorare il vostro approccio al debug di applicazioni o alla soluzione di problemi di ogni genere.

Step #1: definiamo il problema

Innanzitutto dobbiamo avere ben presente quale è il problema che vogliamo risolvere, cercando di imparare quanto più possibile sull’applicazione su cui stiamo lavorando (se ad esempio non è nostra). Nel mio caso, il problema era il seguente: dovevo spostare un form, principalmente una textarea, ma non potevo agire sul suo codice, mentre potevo inserire codice in altre parti della pagina, anche se molte funzioni javascript erano filtrate.

Step #2: analizziamo l’output

Se un’applicazione genera un errore, spesso avremo un messaggio molto chiaro, del tipo “syntax error @ line N”. In altri casi l’applicazione funzionerà, ma ritornerà output diversi da quelli aspettati. Armati di pazienza, analizziamo il sorgente dell’output (in caso di applicazioni che generano HTML).
Nel caso in esame, non avevo molti appigli. Il form aveva associata una classe, ma non un ID e un Name. La textarea poteva essere riferita attraverso il suo Name (inevitabile, in quanto il form usava POST). Inoltre non potevo ricreare il form con lo stesso nome e con lo stesso submit, in quanto sarebbero sorti altri problemi, non rilevanti in questa trattazione.

Step #3: workaround

Una volta identificato il problema nell’output, non corriamo subito a scrivere km e km di codice. Se non si riesce a debuggare l’applicazione, l’idea è di trovare un workaround, un metodo per “aggirare” il problema escludendo o modificando l’output errato. L’idea di base nel mio caso è stata di creare una textarea “clone” che veniva ricopiata, in qualche modo, nella textarea originale, e, su pressione del tasto [invio], provvedeva a inviare (submit) il form “originale”.

Step #4: schema concettuale

Pronti a scrivere codice? Fermi! Mai scrivere senza avere a portata di mano uno schema concettuale preciso. Quindi carta e penna e iniziamo a disegnare un bel diagramma di flusso della nostra idea. Nel caso in esame, lo schema è abbastanza (ma non del tutto) lineare: {nascondere form originale} -> {form clone} -> evento: keypress -> {copia contenuto di form clone in form originale} -> se keypress è [invio] -> fai submit()

Step #5: pseudocodice

No, non dobbiamo ancora scrivere nulla. Innanzitutto non abbiamo ancora definito il linguaggio, ma possiamo farne a meno anche in questo punto, basta sapere se il codice agisce lato-client o lato-server. Nel secondo caso andrà modificato anche il diagramma di flusso. Nel caso del form, è evidente che si userà un linguaggio lato-client (javascript).
Lo pseudocodice sarà di questo tipo:
#evento keydown del form: copia() il testo contenuto dal form clone al form originale.
#evento keypress del form: se_il_tasto_è_invio() procedi con l’invio() del form originale.
#funzione copia(): form_originale.il_testo = questo_form.il_testo;
#funzione se_il_tasto_è_invio(): se il codice ASCII del tasto == 13 form_originale.submit()

Step #6: il codice

Ora siamo finalmente pronti per scrivere il codice sorgente. Il codice di questo esempio è lasciato come esercizio per il lettore.

Step #7: debug

Pensavate di avere finito? Ora bisogna provare il codice, testare ogni tipo di uso (non solo quello ovvio e corretto: altrimenti rischiamo di rilasciare un codice pieno di buchi) cercando di metterci nei panni di un utente inesperto. Per questa parte del lavoro possiamo anche chiedere ad un amico Individuati eventuali bachi riprendiamo lo schema daccapo e rivediamo il nostro procedimento cartaceo, prima di iniziare a modificare per tentativi il codice.

Partorito da Vittorio C. alle 08:16
Tags: Programmazione