Categories
ajax php

Ridondanze…

Mi sono accorto che per scrivere uno stupidissimo form mail ajax enabled tra codice js, html e php spreco circa 100k ed utilizzo qualcosa come 6 diversi file (stili a parte). Di questi il 70% sono di effetti stupidi in js, il 20% in html ed il restante 10% di php object oriented.

La stessa cosa l’avevo fatta tempo fa nell’ottica di web 1.0 (ma facciamo anche 0.5) con php embedded nel codice html ed utilizzando circa 10k.

Alla faccia della ridondanza…

ciuaz

9 replies on “Ridondanze…”

E’ il motivo per cui odio javascript, ajax e web2.0 (che tra l’altro è diventato un marchio registrato).

Io scrivo già web 3.0 ovvero xhtml semantico, accessibile e basta. Senza tanti amenicoli vari che saranno strausati fino a diventare odiati tanto quanto lo sono le tabelle.

Certo, se scrivi la form direttamente in HTML ti viene molto + piccola.
Poi se però vuoi riutilizzare il codice per un’altra form, dovrai riscrivere gran parte del codice.
Invece il codice super-ridondato lo riusi in un attimo, probabilmente basta modificare quelle due righe di php.

ok, sono passato da un estremo all’altro… posso pero’ scrivere del codice PHP poco ridondante, ottimizzato, sicuro e riutilizzabile sempre.. arrivando a 20k ;) [html incluso su un altro file]

il problema di un uso massiccio di ajax è il JS che comunque non è sempre riutilizzabile e bisogna riscriverlo di volta in volta, di caso in caso :(

Se si vuol far avere un’esperienza diversa nell’utilizzo dei siti web bisogna cominciare a pensare ad Ajax e a tutti quei “fronzoli” che complicano la vita al programmatore ma che la semplificano agli utenti.

Dovrei capire che cosa intendi per codice ridondato, ridondare è: descrivere più informazioni/azioni uguali in diversi punti di un progetto, invece di centralizzarle.

Se in ogni pagina PHP che faccio riscrivo il pezzo di codice che mi si connette al db allora ho ridondato il codice. Se separo le componenti model, view, controller allora sono un ottimo programmatore. E se alla fine ho scritto più righe e ho impiegato più tempo poco importa. Ho creato una struttura più mantenibile nel tempo. Mi sono trovato di fronte ad applicazioni gestite senza un minimo di logica strutturale e ora una qualsiasi modifica può portare a seri disturbi mentali il programmatore. Questo tipo di applicazioni sono state create con poco codice (e anche questo è discutibile) in poco tempo.

Per una pagina forse hai ragione te, non ne vale la pena (anche se con librerie come Prototype ne vale, altrochè!) ma con progetti di un certo livello vale veramente pena.

Premettendo che per piccole applicazioni MVC === Evil, considera il carico di lavoro per analizzare i dati di una form e poi inviare un’email validata. Falla tutta lato server. Ed aggiungici ajax per farlo in “tempo reale”.

Poi rifai la cosa senza ajax.

Confronta quanto il codice è mantenibile nelle 2 versioni.

Premettendo che anche le piccole applicazioni possono evolvere nel tempo fino a diventare grandi, penso che non bisogna vedere MVC come un peso ma come un vantaggio a lungo raggio. Penso a RybyOnRails e sono convinto che quella sia la strada giusta.

Ovviamente se devi fare un singola pagina ti dico lascia perdere ma questo è un altro discorso.

Se una piccola applicazione evolve fino a diventare grande significa che hai sbagliato a idearla/progettarla. IMHO se è piccola deve rimanere tale.

E cmq ci sono sempre le “cosiddette tecniche agili” per il refactoring del codice in caso di continua crescita.

Cmq IMHO l’approcio ad MVC per applicazioni web non troppo grosse e/o complesse è un inutile spreco di risorse. Sarebbe come pescare usando delle granate in un barile di pesci…

In realtà non è quasi mai colpa dell’analista/sviluppatore, non è neanche colpa del cliente ma del normale evolversi di un progetto. Con il passare del tempo nascono delle esigenze. Hai fatto bene a citare le metodologie agili perchè nascono proprio per dare una soluzione a questo.

Continuo a non pensarla come te riguardo a MVC, secondo me invece dobbiamo sforzarci di trovare il modo di utilizzare MVC più semplice possibile. Come fanno framework come ROR e Django.

Comments are closed.