Gia' da lungo tempo utilizzo il linguaggio dell'elefantino per realizzare applicazioni basate sul web.
Mi piace, soprattutto rispetto a molti altri sistemi per realizzare pagine web dinamiche; in passato ho usato molto le lungaggini non indifferenti composte da CGI (soprattutto in Perl) da includere magari attraverso i Server Side Includes con il problema che diversi web-server peraltro accettano diverse sintassi per gli SSI, rendendo non facile realizzare pagine web dinamiche.
Il linguaggio e' semplice, di facile lettura e offre una pulizia ed una versatilita' non comuni.
Ma qui si apre la parentesi. Quale che sia il linguaggio lato-server che si usa, e quali che siano le sue potenzialita', il punto e' poi l'interfaccia utente.
Infatti con PHP (cosi' come con tutti i linguaggi lato server), noi possiamo elaborare dati, fare conti, smandruppare dati su diversi database, prendere contenuti dinamici da risorse xml, applicare fogli di stile xls, spingere sull'xmlrpc, analizzare variabili, riempire caselle, tabelle, scrivere centinaia di file semaphore e leggere migliaia di risorse esterne, ma alla fine i dati dovranno essere offerti all'utente. Rigirati, filtrati, coccolati, pettinati e con i connotati rifatti, ma sempre offerti all'utente, e l'utente usa il browser, per cui in qualche modo dopo tutto il lavoro, lo script dovra' sputare codice xhtml.
E qui abbiamo diverse scuole di pensiero, sull'argomento.
Una parentesi prima di continuare: vi invito a visionare un piccolo script che ho integrato a DokuWiki per fornire sull'intestazione del sito data, ora e contatore delle visite direttamente "in-line" (e' ospitato a parte perche' includere codice php su Blogger e' la cosa piu' inquietante con cui si possa dover combattere...)
Ora ritornando al discorso di poc'anzi, come dicevo ci sono molte scuole di pensiero riguardo alla generazione del codice html/xhtml da dare all'utente finale.
Il codice php puo' essere semplicemente intercalato in mezzo al codice html (d'altronde questa e' l'abitudine peraltro di chi viene da vecchie versioni di IIS ed e' abituato ad usare il tag script...), alleggerendo il carico del server. Oppure puo' essere semplicemente sbattuto fuori con una o piu' righe di echo o print, ma se troppo intercalato nella programmazione, cio' comporta una non facile leggibilita' del codice.
Altre scuole sono quelle che predicando la pulizia del codice a tutti i costi, praticano quello che in gergo viene chiamato "Ufficio Complicazione Affari Semplici": se il linguaggio supporta l'OOP (e - guardacaso - php lo fa) perche' non pensare alla pagina HTML come un intero oggetto da smandruppare per bene. Mi sa di inquietante che l'intera funzione di output e' data nelle mani di una classe che va inizializzata e riempita di metodi per sputare fuori tutto quello che va dal doctype in poi, che sebbene dia una maggiore pulizia formale del codice, rende lo stesso dannatamente intricato (creare una classe, definire un metodo, inizializzare la classe, applicare il metodo, chiudere la classe: e mo' qual'e' il punto nel quale non mi da in output quel dannato paragrafo?).
Io sono di quella scuola che preferisce infilare gruppi di echo nelle varie funzioni, ma se devo fare codice particolarmente complesso penso che userei il metodo della costruzione della pagina per mezzo di funzioni statiche [print_html_doctype($dtd), print_html_header($page_title, $meta_keywords...), print_html_body($lang, $xml_lang...) eccetera], ma non so se sceglierei di utilizzare gli oggetti pure per questo genere di procedure.
Ho visto (e vedo spesso) programmatori talmente fissati con gli oggetti da buttarsi a pesce nel costruire anche le routine piu' stupide: che dire di una subroutine in PHP per estrarre un fortune che sembrava un esercizio di programmazione per chi ha letto "Come scrivere programmi incomprensibili" di Davide Bianchi. Una classe per gestire il file dei fortune, una per gestire l'elaborazione di un valore casuale, una per estrarre dalla classe che apre il file un fortune casuale in base all'altra classe, ed infine una classe per stampare il contenuto del file. Ora, non voglio dire che con un colpo di join(), split() e rand(), in tre righe si faccia la stessa cosa, pulita e leggibile, ma...
... in questo frangente amo dire che se si buca una gomma, si puo' sollevare l'automobile efficacemente sia con il cric che con una gru... (-:
E voi, invece? Quale metodo applicate per definire l'output xhtml delle pagine/script/servlet? Giri di print? Inclusione del codice? Classi con ereditarieta' fino alla 30ma generazione? Chi se ne frega ci pensa il grafico web a fare l'impaginazione? (-:
8 commenti:
Java/JSP/Struts e compagnia, che sono un tantinello più avanti dello spaghetti-coding tipico del PHP (per non parlare della sicurezza e di mille altre questioni tecniche).
Si, ma io ho chiesto "Quale metodo applicate per definire l'output xhtml delle pagine/script/servlet? Giri di print? Inclusione del codice? Classi con ereditarieta' fino alla 30ma generazione? Chi se ne frega ci pensa il grafico web a fare l'impaginazione?"...
... quanto alla sicurezza, dissento: buona parte dei problemi di sicurezza sono dovuti a bug, che sono un problema comune. Diceva il buon Leonardo Serni: "Siamo seri. Per fare una ricerca utente alla fine nell'SQL dovranno finire dei dati forniti dall'utente; verificati, untainted, rifatti col naso alla francese da Pitanguy, ma pur sempre dati utente! E se ci sono dati utente, c'e' la possibilita' di una backdoor.", pertanto se io piglio un campo utente e lo do in pasto senza il minimo controllo al DB, indipendentemente dal fatto che abbia utilizzato php, o asp.net, o c#, o java, o perl o mio nonno in carriola, lo script sara' esposto a sql injection.
PS: a proposito di bug: se usate sui commenti la forma "Nome/URL" e' bene che indichiate la vostra homepage come "http://indirizzo", perche' a quanto pare blogger non digerisce "www.qualcosa" in maniera corretta...
Utilizzando Struts/JSP è implicito utilizzare il pattern MVC, come si usa per la quasi totalità del resto dei framework per lo strato di presentazione.
Sul discorso sicurezza è ben noto che i problemi del PHP risidedono nel fatto che sia interpretato e fortemente non-tipizzato. Anche la stessa operazione dell'eseguire una query cambia radicalmente, dato che in java per esempio esistono framework che implementano l'ORM come hibernate. Fare una query normalissima è cambia comunque nettamente, dato che si tende ad utilizzare strumenti come ad esempio gli Statement (che si usano anche ad esempio per le Store Procedure) che fanno già tutti i controlli possibili ed immaginabili.
Senza contare che ovviamente è impensabile usare il PHP come infrastruttura per web application estendibili e con architetture non banali (anche sotto il profilo della sicurezza).
Uhm, credevo che il pattern MVC fosse usato solo con jxml (e' stata l'unica cosa che ho approfondito su Jakarta, ed e' un arma impropria): estrarre dati da uno script java smandruppando xml a suon di xslt infilato in-line... Ammetto comunque i miei limiti (d'altronde ho detto che conosco bene PHP); quanto alle soluzioni enterprise, ovviamente il discorso e' troppo complesso (e non conta solo la sicurezza: conta anche la rapidita' di esecuzione del codice e quanto carico vada lasciato sul lato server, rispetto a quanto invece su quello client...). Io parlo di scripting per il web, rapido rapido. Mi rivolgo a chi programma come me in php, o in asp, o in perl, in python... (-:
C'e' il grafico e l'esperto di User Experience (usabilista), l'esperto di accessibilità e l'impaginatore HTML (solitamente una persona puo' ricoprire + ruoli). Il ciclo di produzione solitamente e' Grafico->User Experience->Accessibilista->Htmllista con i vari ricicli. Il problema ricorrente è cercare di minimizzare la dipendenza di questo mondo con quello degli sviluppatori (Java/Jsp, Php, Perl, ...). Una delle soluzioni tecnologiche che vengono maggiormente usate per risolvere il problema suddetto e' l'utilizzo di un motore di templating, quello + usato in PHP e' sicuramente Smarty.
Spero di esserti stato utile.
Mah, la mia curiosita' era di trovare qualcuno che *veramente* usa xml+xslt+css...
... e' la strada che sto per prendere io... (((-:
Cercavi qualcosa di questo genere?
Premesso e preso atto del fatto che non cercavo un bel niente, dato che ero solo curioso di sapere (come ripeto per la terza volta) altre persone impegnate nella programmazione web che scuola di pensiero seguissero per l'output dei dati in xhtml... dico: premesso questo, casomai parlavo di questo argomento.
Posta un commento