Undolog.com

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...

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...

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...