««« | »»»
Content-out approach: vantaggi ed effetti collaterali
In un nuovo progetto a cui sto lavorando sto avendo modo di toccare con mano i vantaggi dell’approccio content-out, applicato anche ad applicazioni web e combinato con l’uso dell’html come mezzo di prototipazione.
Il primato del markup
Il markup è più pulito, con meno classi e id inutili, la sua struttura generale mi sembra più logica e chiara. Questo vale anche per l’html che poi verrà generato dal server, dove mi sono concentrato sulla qualità del markup senza pensare a come sarebbe stato poi creato.
Oltre l’html
Visti i risultati positivi, ho provato a fare lo stesso con javascript e anche qui ho avuto un riscontro simile. Il miglioramento è stato evidente soprattutto nei punti in cui erano previste interazioni ajax. Il non passare subito all’implementazione della risposta del server, emulando il comportamento con degli stub, ha isolato e quindi reso più evidenti le interfacce del sistema, rendendolo più modulare.
Funziona? E perché?
Nel caso del javascript non è che si possa parlare di un approccio content-out vero e proprio, se non come analogia: da una parte ci si concentra sul trovare il giusto markup per l’informazione da mettere in pagina – proseguendo poi verso la struttura più esterna – senza fare affidamento sulla presentazione per dare un ordine al contenuto; dall’altra si rimane sempre in javascript senza cedere alla tentazione, per così dire, di spostare il problema dall’altra parte, sul server.
Mi sembra che in questo modo si riescano a definire molto meglio i confini fra i vari layer, utilizzandoli in modo più appropriato.
Per proseguire
Commenti e trackback sono disabilitati.