Undolog.com

La versione 7 del browser Microsoft è stata (finalemente) rilasciata in lingua inglese (quasi contemporaneamente è stata rilasciata la release 2 di FireFox). A breve – tramite il servizio di aggiornamenti automatici di Windows – sarà installata su milioni di macchine, come patch del sistema. Qualcuno ha già criticato questa mossa di Microsoft gridando all’ennesimo comportamento scorretto. Agli sviluppatori Web, tuttavia, interessa più sapere che fine farà Internet Explorer 6 (IE6) e come dovranno comportarso nello sviluppo di siti Web.

Il rilascio tramite Windows Update è previsto per l’inizio di novembre! Ne deriva che nel giro di una settimana IE6 sarà bello che sepolto. Gli sviluppatori Web dovranno ovviamente aggiornare il proprio PC, ritrovandosi quindi sprovvisti di una versione 6 su cui effettuare le canoniche prove di compatibilità.

Risulta infatti evidente che chi – come noi – è maniaco degli aggiornamenti e deve assolutamente possedere l’ultima release di un software, si trova tra l’incudine e il martello. Inoltre – come è ovvio – IE6 è morto! Ed era anche ora! Un browser candidato ad essere sicuro – se mai ce ne sarà uno – nel prossimo futuro (prossimi giorni) è sicuramente IE7, visto che sarà quest’ultimo a subire patch (service pack) di sicurezza.

Da sviluppatori comprendiamo che IE6 è ormai abbandonato! Inoltre Microsoft ha esplicitamente consigliato di passare urgentemente alla versione 7, se ci fosse bisogno di ribadirlo. Gli sviluppatori Web dovranno dotarsi di una macchina con IE6 per eseguire i test? Evitando di aggiornarla? Subendo così possibili attacchi da tutte le parti o evitando di andare in rete?

La soluzione più ovvia – e vantaggiosa per Microsoft – è che sviluppatori ed end user passino immediatamente a IE7, che lo vogliano o no!

Continua...

C’è un motivo molto importante per preferire l’inserimento dei contenuti via PHP – lato server – in una pagina Web rispetto all’uso di Javascript – lato client. Nello sviluppo degli strumenti di outing services del CMS getmePage utilizzato su applick.com era possibile sfruttare Ajax come engine di recupero HTTP dei dati server. Il problema, in questo caso, era che si aveva a che fare con i contenuti di un sito, contenuti che vengono indicizzati dai crawler di ricerca come googlebot! I crawler non eseguono Javascript, rendendo così vuota una pagina agli occhi di googlebot. Oggi sono i contenuti a fare la differenza nelle indicizzazioni nei motori di ricerca, quindi bisogna fare attenzione a come vengono generati i contenuti in una pagina. Quello che vede l’enduser non è quello che vede un tool come googlebot. Questo è uno dei motivi che hanno determinato la scelta di PHP nell’engine di recupero dati dell’applick getmePage. PHP, infatti, viene eseguito dal Web Server prima di inviare la pagina al client. Ne deriva, così, che quello che vede un crawler è quello che vede l’enduser.

Continua...

Come già affrontato su “Javascript vs PHP” (o altro: ASP, CFM, …), la questione di inserire o meno un kernel Web2.0 negli script Javascript, invece di lasciarlo – in maggiornaza – lato server, può creare confusione se non sconcerto. Tuttavia ci sono degli ottimi motivi per favorire il server rispetto al client, motivi che non hanno niente a che fare con il Web2.0 che, al contrario, punta i riflettori proprio sugli script Javascript.

Continua...

Per chi sviluppa moduli e FORM di contatti, esiste la necessità di verificare l’immisione di un indirizzo di posta elettronica. Oggi più che mai, con demoni pronti ad eseguire SPAM ovunque, è bene tutelarsi da “furbetti” pronti a sfruttare i moduli HTML per inviare mail illegali o eseguire hack per SPAM e quant’altro.

Continua...

Ecco alcuni brevi consigli su come usare class e id nei fogli di stile. Tenete subito in considerazione che l’uso di tecniche Javascript avanzate, come lo stesso uso di motori Ajax, può entrare in conflitto con i consigli esposti qui! E vedremo alla fine il perchè.

Continua...

A causa forse delle incompatibilità stilistiche e di output – ancora presenti – tra i vari browser, non tutti conoscono le innumerevoli potenzialità dei fogli di stile. Vogliamo mostrare, quindi, alcune caratteristiche della sintassi CSS sconosciute ai più e per ricordarci quanto poco – spesso – sfruttiamo a pieno gli strumenti che abbiamo a disposizione.

Nota: tutti gli esempio sono stati provati su Firefox 1.5.0.5

Selezione per attributi

Questa caratteristica, spesso indicata cone CSS2 avanzata, permette cose strabiglianti, se ci riflettiamo un attimo. Il maggior vantaggio lo si ottinene lato HTML, dove non sono necessarie classi o id per distinguere i TAG nel CSS. Sono proprio gli attributi – comunque presenti – nel TAG ad indicare quale stile associare. Inoltre qualsiasi attributo del TAG può essere preso come selettore: alt, title, accesskey, ecc…

Selezione per profondità

Questo tipo di selezione è a dir poco spettacolare, se considerate che può essere sommata a quella precedente. Essa permette di definire la gerarchia degli elementi. Guardando l’esempio qui sotto ci si rendo subito conto della straordinaria portata di questo tipo di selezione, che mantiene il codice HTML pulito e senza indicatori superflui.

Addirittura, giusto per concludere questo sorvolo, oltre a last-child esiste first-child e – fantastico – first-letter! Provate voi.
Abbiamo ovviamente appena sfiorato l’argomento, alquanto vasto a dire il vero, che vede i CSS come strumento evoluto per la definizione del layput di pagine. Esistono altri selettori e comportamenti e grandi novità per le specifiche dei file CSS di futura generazione.

Continua...

Lo sviluppo di web application con tecnologie di tipo Ajax ha messo in luce tutte le limitazione del protocollo di connessione Internet HTTP. Presto o trardi qualsiasi programmatore si scontra con l’esigenza – ad esempio – di avere una connessione permanete con il client. L’invio verso i client di un broadcast message è tutt’oggi impossibile senza ricorrere a qualche rischioso artifizio!

Nello scenario Internet, tuttavia, l’uso di componenti speciali come ActiveX Object, Flash o Java Applet, permettono di aggirare ottimamente il problema. Spesso, infatti, ci si chiede se l’oggetto HTTPRequest (mattone base per esperienze Ajax) non sia sostituibile da un componente ActiveX o utilizzando un filmato Flash casomai invisibile!

Questa è una delle questioni più struggenti nell’ambito dello sviluppo di web application di nuova generazione. A dimostrarlo, infatti, ci sono tutta una serie di “beta” web application che utilizzano tecnologie miste per risolvere le varie problematiche che si presentano – e che l’HTTPRequest non è in grado di svolgere. Lo stesso FlickR, uno dei photo-blog di maggior successo, ricorre all’uso di filmati Flash in alcune sezioni del sito. Ci sono poi realtà ancora più articolate dove sono presenti Applet Java o controlli ActiveX per arrivare li dove nessuno – Ajax – era mai giunto prima!

Quello che andrebbe fatto, a breve termine, è un nuovo standard per l’HTTPRequest, chiamandolo addirittura in un altro modo. Riuscire ad ottenere un oggetto, presente in tutti i browser, capace di realizzare connessioni permaneti e in grado di manipolare più protocolli. Tuttavia ciò sarebbe una fantasticheria per gli sviluppatori ma, ragionandoci bene, potrebbe portare alla morte di Internet come la conosciamo.

Quando l’HTTP fu ideato la rete globale come la conosciamo oggi aveva velocità e utenti ben differenti. I punti importanti dell’HTTP sono:

• Connessione al Web Server
• Richiesta di un file
• Disconnessione

L’HTTP nasce proprio con l’idea di base di non gravare sulla trasmissione via rete; minimo supporto di handshake! Ancora oggi quando il browser richiede una pagina ad un Web Server, svolge proprio i tre passi indicati sopra. E’ importante notare come Google abbia sviluppato un software come Google Earth per poter superare gli ostacoli di connessione e altre cosine. Internet è pronta a sopportare connessioni permaneti? Noi pensiamo che sia prematuro. La maggior parte degli hosting crollerebbe in pochi secondi. Banda e CPU dovrebbero essere ben più capaci per sopportare la mole di traffico che si produce oggigiorno.

Le realtà che supportano connessioni permaneti sono ben circoscritte e fanno sempre uso di componenti e tecnologie specifiche e sofisticate.

Continua...

Corre voce che attualmente è in corso una discussione sull’uso di Javascript come costruttore di contenuti HTML. In particolare il dilemma assilla l’universo Ajax. Sotto questa sigla si cela un metodo che permette di contattare il Web Server tramite script Javascript, senza che il browser debba ricaricare l’intera pagina con il conseguente – e fastidioso – “fliker” video.

Il fatto che questa tecnica permetta di comunicare con il Web Server significa, in pratica, che si possono inviare – e ricevere – informazioni dal Web Server senza che l’utente – di fatto – se ne accorga! Su quest’ultima affermazioni sarebbe il caso di aprire una discussione a parte.

Tornando alla nostra questione la domanda principale è la seguente: una volta ricevuta la risposta dal Web Server chi deve costruire l’impalcatura HTML tale da poter inserire la risposta nella pagina corrente? Lo deve fare il Web Server al momento dell’invio della risposta o è un compito demandato a Javascript lato client ?

In pratica c’è chi sostiene che il modo migliore è quello di far impacchettare la risposta completa direttamente lato server; così che il client Javascript deve solo prendere ed inserire (get & insert). Altri, invece, sostengono che la cosa migliore sia ricevere i dati spuri, raw, in una struttura XML magari ed elaborare il tutto lato client, tramite Javascript, e sempre con Javascript creare l’impalcatura HTML necessaria per l’inserimento sulla pagina.

Sembra subito evidente, però, che non è possibile – a priori – sostenere un modello rispetto all’altro. Entrambi, evidentemente, devono essere contestualizzati. E’ possibile che in alcuni casi far impacchettare tutto al Web Server risulti effettivamente la scelta migliore, sia in fase di sviluppo che in velocità di trasmissione.

C’è da dire subito che l’idea di caricare grossi quantitativi di codice Javscript sul client non è una bellissima soluzione. Dico questo in ricordo della scalabilità. Un sistema che si presenta già pesante nelle sue fasi iniziali, ha ben poche possibilità di progredire in tranquillità in futuro. Inoltre le ancor diffuse incomptibilità tra i browser disponibili, quindi lato client, rendono stancante sviluppare codice Javascript troppo articolato. Tuttavia c’è chi lo fa! Indubbiamente.

La morale, ad oggi, con i browser e i sistemi operativi che abbiamo, sembra essere quella che ognuno deve scegliere la propria via, domani si vedrà. Nel nostro sito Web Applick.com, il codice è stato scritto utilizzando entrambi i metodi, a seconda del caso.

Domani, magari, usciranno dei browser con codice preconfezionato a bordo! Verrà sicuramente rivisto il componente HTTPRequest. Per ora questa tecnica deve la sua ri-nascita (vedi uso del TAG IFRAME) sia al minimo standard realizzato sul componente HTTPRequest, alla sua presenza e implementazione nei browser e sia all’aumento di banda-media disponibile ai navigatori Internet. L’HTTPRequest è comunque un subcanale HTTP, ne più ne meno. Inviare un codice XML invece che HTML non fa molta differenza, sniffando la rete ce ne rendiamo subito conto. Forse questi sono lamenti di qualche altra cosa che va al di là della questione Ajax. E’ innegabile che una certa parte della comunità Internet chiede un cambiamento, delle modifiche strutturali. Si è parlato – giustamente – delle connessioni pemanenti, che certo non hanno niente a che vedere con la politica attuale (e originaria) del protocollo HTTP.

La realtà, alla fine, potrebbe essere quella di ammettere che la tecnologia attuale di Internet è superata. I suoi protocolli, ideati per altre velocità di rete e altre condizioni, sono obsoleti.

Continua...