Ieri ho provato per la prima volta Internet Explorer 9, che apprendo essere arrivato alla Beta 7 (o Platform Preview, come dicono loro) e con un rilascio previsto nel 2011. Bene, dico. Con il successo di Windows 7, ci sono le potenzialità perchè anche l’evoluzione di un browser del tutto insufficiente come IE8 sia finalmente qualcosa di buono.

…No, nient’affatto.

La nuova release di casa Microsoft soffre di moltissimi dei problemi dell’attuale incarnazione. Il software su cui lavoro ha come target primario, per ragioni aziendali, naturalmente, proprio il nostro beneamato browser; inoltre, ripiego su Firefox per test di compatibilità cross-browser e soprattutto per il debug del codice Javascript e, infine, uso correntemente Chrome per tutto il resto. Per cui, ho modo di confrontare i vari programmi e ho potuto conoscere da vicino molti dei problemi che affliggono Internet Explorer 8.

Alcuni di questi, diciamolo, sono cose di cui l’utente medio non si potrebbe mai accorgere; ma da che mondo è mondo, se molti consultano il Web o utilizzano applicazioni thin-client, significa che qualcuno crea i siti e ha bisogno di buoni strumenti per farlo. Quindi si può capire come avessi sperato di vedere qualche miglioramento all’alba del 2011.

Non dirò delle innovazioni, pure molte: supporto, seppur parziale, a CSS3, accelerazione 3D delle pagine, HTML 5. Tutti i browser di nuova generazione, attualmente in prova, hanno le stesse caratteristiche e le sfruttano meglio. Ecco invece una breve lista dei problemi non risolti in Internet Explorer 9 Beta 7:

• L’installazione. Firefox, Chrome, qualsiasi altro browser si installa come un normale programma, velocemente, con la possibilità di cambiare idea e annullare in ogni momento e pronto all’uso appena installato. Perchè IE9 non mi dà la possibilità di annullare l’installazione? Perchè ci mette così tanto? E perchè sono costretto a riavviare il pc dopo averlo installato?
• La nuova interfaccia è un tentativo mal riuscito di imitare Chrome (e Firefox 4, ora in beta). Ma siccome si tenta di essere “originali”, hanno messo la barra degli indirizzi sulla stessa riga delle tab. Risultato? C’è spazio insufficiente per l’una e per l’altra. L’indirizzo di questo blog non ci sta per intero.
• L’apertura del browser stesso e di nuove tab è sicuramente più veloce di IE8, ma nemmeno lontanamente ai livelli di Chrome. Se il browser è “integrato” con i componenti Windows, allora perché è così lento?
• Minuzie che contano, come Apple insegna (e anche Windows 7). Il pulsante di chiusura delle tab che non compare se la tab non è focalizzata. Funzionalità incoerenti nel debugger. Integrazione con la Superbar scomoda e poco gestibile.
• Bug Javascript e HTML, come l’errata interpretazione dell’attributo className e il comportamento fuori standard di innerHTML, non solo non sono stati risolti, ma pare che nemmeno siano stati presi in considerazione. In generale, il rispetto per gli standard W3C è tuttora fuori dalla finestra.
• E, ultimo ma non ultimo, il debugger. Era osceno prima e tale è rimasto. Gestire il codice di un sito con molti div innestati è simile a spingere il masso di Tantalo. Modificare il codice CSS on the fly porta a comportamenti imprevedibili. Per avviare il debug Javascript bisogna ricaricare la pagina e soffrire un grave peggioramento delle prestazioni fino al riavvio del browser.

Ora, la Microsoft è una grande azienda. Grande da 62 miliardi di dollari di fatturato e 89.000 dipendenti. Com’è possibile che il loro browser faccia così pena da essere inutilizzabile? Nessuno si rende conto di quanto sia indietro rispetto alla concorrenza? Un’altra occasione sprecata per Microsoft, l’ennesima.

Invito chi voglia provare di persona a visitare Beauty Of The Web. Un sito pensato per fare da showcase alle potenzialità di Internet Explorer 9 e infarcito della peggiore propaganda politica. Confrontate le prestazioni del browser “d’elezione” con Chrome 8.x (l’attuale) o con Firefox 4 beta. Come si spiegano i risultati?

Ok, il gioco di parole nel titolo sta diventando vecchio. Prometto che è l’ultima volta.

Follow-up alla discussione di ieri: ho trovato quest’ottima serie di slide su alcune buone pratiche nello sviluppo di web applications con Struts. Si riferisce a Struts 1.x per la verità, ma alcune cose non sono cambiate così tanto.

Punti salienti:

Remove business logic to a business facade that the actions can call.

Actions are a necessary evil. Every line of code in an Action is guilty until proven innocent.

Do not embed business logic in action classes. [Repetita juvant!]

Avoid exposing Domain Models.

Behind your facade, consider using a data access package. [i.e. Hibernate]

In parole povere, sono portato a considerare che la soluzione più corretta sia la numero 1. Corretta fino a prova contraria, naturalmente.

Fonte: Struts Best Practices (Struts University Series)

Premetto che usare dei pattern “preconfezionati” senza bene capire ciò che sto facendo, non è quello che voglio.

Sto lavorando ad un progetto Java, una web application che mi ha permesso di inoltrarmi nel favoloso mondo del pattern MVC, di Spring, Struts, Hibernate e quant’altro. Oltre a numerosi mal di testa e problemi nel chiedersi “Cos’è meglio? Quale dei 300 approcci diversi alla soluzione di un problema funziona meglio, è più manutenibile, eccetera?”

Prendiamo ad esempio l’implementazione della parte “Model” nel pattern MVC. Dell’accesso al database se ne occupa il layer di persistenza, è vero, con i suoi puliti DAO che non fanno altro che implementare funzionalità CRUD e quanti tipi di find() siano necessari per entità. Ma chi chiama i DAO e da dove? E dove può risiedere la business logic?

Due dei pattern che ho provato ad implementare sono questi:

1. Action (Struts) -> Model (Spring, w/ business logic) -> DAO (Spring + Hibernate)

   dove le frecce indicano “Chiama”. Questo pattern mi sembra chiaro e lineare, soprattutto molto lineare, in quanto non si mescolano i punti di accesso ai vari layer dell’applicazione. Ma soffre di duplicazione di codice, con nomi di metodi ripetuti lungo i vari strati e solo l’ultimo veramente significativo. Certo, questo potrebbe non essere un problema.

   Poniamo l’esempio di una serie di save(), che ha come scopo ultimo tradurre dei campi in una form nella riga di una tabella. Il save() della action potrebbe passare come parametro il dato preso da una form sulla pagina. Il save() del modello (che a questo punto, potrebbe anche essere chiamato “servizio” visto che non è solo un modello) potrebbe popolare condizionalmente i campi dell’oggetto in questione. Infine, il save() del DAO andrà ad effettuare l’operazione di persistenza sull’oggetto creato.

2. Action (Struts) -> Service (Spring, w/ business logic) -> Model (Spring)
   |
   +--> DAO (Spring + Hibernate)

   Un po’ meno lineare e più convoluto, anche se non difficile da capire. Il modello, in questo caso, assomiglia pericolosamente ad un DTO che ritengo poco utile in questo caso, essendo destinato a rimanere nello stesso layer e nello stesso contesto dell’intera applicazione. Quando implementato, il Model risiede in sessione.

   Ha il vantaggio di separare molto chiaramente business logic e dati, ma è davvero necessario quando l’uso di un ORM come Hibernate costringe già l’utente a scrivere delle Entity di puri dati? L’archetipo del modello dovrebbe essere una Entity; tutto il resto è duplicazione o aggregazione.

3. Action (Struts) -> Service + Model (Spring, w/business logic)
   |
   +--> DAO (Spring + Hibernate)

   basato su alcune invarianti:

   • La Action deve rimanere priva di logica di business.
   • Il Model non chiama il DAO.
   • La Action implementa l’interfaccia ModelDriven.

   In questo modo, una Action può o meno richiamare un Model (e contestualmente, implementare ModelDriven per ragioni di validazione e facilità d’accesso) per dati che richiedono qualche tipo di elaborazione. A sua volta, il Model potrà o meno risiedere in sessione per questioni di performance. Si evitano catene di metodi con lo stesso nome ed in ogni caso, è la Action che si preoccupa di richiedere operazioni di persistenza al DAO.

   Il che è un problema in sé: si ottiene l’effetto di doversi ricordare di chiamare il DAO ogni volta. Dover chiamare metodi nella giusta sequenza non è praticamente mai un indice di buona programmazione.

Mi sto documentando per essere meglio illuminato sui pro e i contro di ognuno di questi approcci. Al momento, il primo mi pare il più flessibile e semplice, perchè permette di implementare funzioni comuni senza fatica (ad esempio, misurare il tempo di esecuzione di alcune operazioni su database senza esporre l’interfaccia ovunque o usare classi statiche). Di certo c’è solo che il mondo Java J2EE è vasto e complesso e passerà molto tempo prima che io possa comprenderlo appieno. Se mai succederà!