VNC ormai è diventato uno standard per il controllo remoto dei sistemi con interfaccia grafica: basandosi su un protocollo aperto le implementazioni sono state numerose.

Uno dei suoi grossi limiti è stato quello di creare non pochi problemi a chi avesse voluto utilizzarlo dietro un proxy da una rete aziendale, ad esempio) a meno di utilizzare tunnel ssh (quando possibile) per veicolare il traffico: problema risolto brillantemente da servizi come LogMeIn che tuttavia, oltre ad appoggiarsi a un sistema proprietario comporta l’obbligo di veicolare tutto il traffico (benchè criptato) sui loro server.

Leggendo questo articolo su Mashable vengo a conoscenza dell’esistenza di un progetto chiamato AjaxVNC: si tratta di un server VNC scritto in Java che include un piccolo webserver.
“Bella  scoperta, il webserver lo ha anche la versione ufficiale di VNC, sulla porta 5900!”, direte, ma  quello di AjaxVNC è leggermente differente.
Mentre il VNC ’standard’ espone un webserver che permette esclusivamente di avviare un’applet per collegarsi al server utilizzando la normale porta 5800, AjaxVNC fornisce un client interamente scritto in Ajax, quindi permette di veicolare tutto il traffico sulla porta 80, scavalcando facilmente proxy e limitazioni.

Il progetto è ancora giovane, e le prestazioni non sono assolutamente entusiasmanti, ma si tratta senza dubbio di un buon inizio!

A chi, come me, sviluppa utilizzando molto javascript e ajax sara’ sicuramente capitato: caricate un pezzo di pagina con le vostre belle funzioni asincrone e il javascript contenuto nel segmento caricato non viene eseguito.

La soluzione da me utilizzata e’ un trucchetto che definirei ‘zozzo e brutto’, ma funzionante.

Creare una immagine da 1 pixel, inserirla nella pagina da caricare

<img src="immagine.jpg" onload="Funzione();">

e richiamare, nell’evento OnLoad dell’immagine, la funzione javascript da eseguire.

Ieri ho avuto il piacere di seguire l’ottimo Gianpiero nella creazione di una pagina che tramite il javascript e le solite chiamate asincrone permettesse di:

1. Caricare un elenco di indirizzi dal database
2. Effettuare il geomapping dei suddetti indirizzi
3. Salvare le coordinate cosi’ ottenute sul DB.

Il risultato lo potete trovare sul blog di Gianpiero.

Nell’ultima versione di Morfik WebOS gli sviluppatori hanno lavorato molto per correggere il noto problema di lentezza dell’ambiente…come scritto nella newsletter ufficiale:

The highlights of this release is SPEED – better than 10X faster for incremental compiles

Senza dubbio l’applicazione è piu’ reattiva e la compilazione non è piu’ biblica: comincia a essere utilizzabile!

Ho scoperto casualmente Morfik, un ambiente di sviluppo per applicazioni web interessante e a mio avviso rivoluzionario:

WebOS AppsBuilder brings extreme simplicity to the design of sophisticated AJAX applications without compromising their functionality. You don’t need to write any HTML, XHTML, XML, JavaScript or CSS. It has never been easier to create highly interactive web sites and applications – and you don’t even have to learn a new language or new technologies to do it!

Si tratta di un ambiente RAD (la pagina si disegna trascinando i controlli a colpi di mouse) e i linguaggi di scripting utilizzabili sono svariati (Java, C#, Basic, Pascal).
Ma la vera particolarità è data dal metodo di distribuzione delle applicazioni: un volta compilato il progetto ci si ritrova con un singolo file binario (compilabile al momento per Windows e Linux) contenente le nostre pagine, i nostri script, il webserver (apache) e il database (Firebird).
Una volta avviato il file vengono avviati i server e viene aperta una pagina del browser con l’applicazione, che da questo momento risulta fruibile anche da altri PC presenti sulla rete locale.

Che dire? L’ambiente di sviluppo è ben fatto, con integrati il designer per i form, un buon debugger e un discreto designer per il database.
Purtroppo, tutto l’ambiente soffre di un  problema che a  mio avviso è estremamente  penalizzante:  è LEEENTO!
La compilazione  di un progetto semplicissimo (singolo form, 2 componenti) richiede ben 90 secondi, tempi che quasi si raddoppiano nel caso di una applicazione ‘reale’.
Inoltre,  nonostante sia possibile crosscompilare il progetto anche per linux (e in futuro per MacOsX e FreeBsd) l’ambiente di sviluppo viene rilasciato escluivamente per windows.

In ogni caso il progetto deve ancora crescere, i presupposti però sono ottimi!

Tempo permettendo sto continuando lo sviluppo del mio KAjaxFramework.

Nella primissima versione ho focalizzato lo sviluppo esclusivamente sull’interfacciamento con la base dati, permettendo di sviluppare quasi esclusivamente lato client demandando ai componenti lato server quasi esclusivamente i compiti di lettura/scrittura sul database.
Volutamente avevo tralasciato il fattore ‘visuale’: nessun effetto grafico tanto caro alle applicazioni Web2.0

Dovendo pero’ iniziare un nuovo progetto basato proprio sul mio framework mi sono rimboccato le maniche e applicando la filosofia della Extreme Programming ho riscritto quasi completamente il codice riguardante la presentazione dei dati.

Le modifiche sono parecchie, vi riassumo le principali:

1. Gestione piu’ pulita dei layer: nella vecchia versione i DIV contenenti i MessageBox venivano creati sulla pagina all’atto del caricamento, con degli orridi ‘document.write’, e poi tenuti nascosti fino al momento in cui venivano utilizzati. Nella nuova versione, ogni DIV viene creato al momento in cui deve essere utilizzato e rimosso dal DOM quando non piu’ necessario.
2. Gestione semplificata del Drag&Drop: creare un oggetto ‘draggabile’ ora e’ piu’ rapido e semplice, basta richiamare all’evento OnClick dell’oggetto la funzione dragStart();
3. Dissolvenze: gli oggetti creati possono essere fatti apparire e scomparire con un effetto di dissolvenza. Non solo uno ’sfizio’ grafico: a mio avviso concorrono a rendere l’interfaccia piu’ dinamica (nei tempi necessari alle dissolvenze le funzioni di scambio dati continuano a lavorare, dando all’utente l’impressione di minori tempi di risposta dell’applicazione).
4. Menu’ Contestuali: E’ possibile associare a un oggetto un menu’ contestuale, visualizzabile con il click del tasto destro del mouse.

Per quanto riguarda le funzioni di interfacciamento con la base dati, niente e’ cambiato.
Ultima nota: non ho avuto ancora tempo/voglia di scrivere la documentazione, quindi per capire nel dettaglio come funziona l’accrocco dovete spulciarvi i demo che ho realizzato.
Per qualsiasi dubbio lasciate un commento sul post o scrivetemi in privato: non assicuro tempi di risposta immediati, ma faro’ del mio meglio!

Potete vedere all’opera le novita’ del framework in questa Pagina Demo.

Per ulteriori informazioni e per scaricare i sorgenti aggiornati questa e’ la Pagina Del Progetto su Google Code.

Nel mio precedente post avevo scritto che avrei pubblicato appena possibile il mio KAjaxFramework su SourceForge: ho avuto pero’ modo di apprezzare la struttura a mio avviso piu’ semplice e versatile di Google Code, decidendo quindi per un cambio di destinazione.

Se qualcuno vuole partecipare allo sviluppo o semplicemente dare uno sguardo, ecco la pagina del progetto su Google Code.

Eh si, ho scritto veramente poco ultimamente…sono giustificato pero’: ho lavorato parecchio.

In ufficio ho da seguire il solito $MegaApplicativoGlobale , una bestia multiforme MSSql+ASP+AJAX+tantealtrecose che muta continuamente nella forma e nelle specifiche (la data di consegna della primissima versione gravita intorno alla meta’ di dicembre…vedremo…:-P), mentre i miei lavoretti di ‘libero consulente’ mi hanno permesso (grazie ai tempi di consegna piu’ ‘dilatati’) di sperimentare.

La cellula primitiva di $MegaApplicativoGlobale nasce da una serie di esperimenti (qui e qui) nei quali mi divertivo in delle web applications a dividere nettamente il livello client da quello server.

Viavia ho sviluppato una serie di componenti lato server e funzioni in javascript che mi permettessero di mandare avanti e indietro dati tra client e server in maniera asincrona utilizzando l’XML (non mi e’ nuova questa tecnologia, vero? ).

In breve sono arrivato a un mio personale ’standard’ di sviluppo: per quanto riguarda l’accesso ai dati un unico componente lato server che accetta come parametro una stringa sql e restituisce una struttura XML contenente i dati restituiti dal DataBase.
Ho sviluppato il suddetto componente sia in ASP che in PHP…piu’ avanti capirete perche’.

Sul livello client sono presenti una vasta gamma di funzioni che accolgono la struttura XML inviata dal server, la elaborano e presentano sulla pagina (viva il DOM e chi lo creo’) i dati in varie forme (tabelle, comboBox ecc…).

Aggiungendo alle funzioni per la manipolazione dei dati un po’ di codice per modificare degli elementi della pagina mi sono trovato tra le mani un accrocchio che ho scoperto essermi parecchio utile: essendo il componente lato server per l’interfacciamento con il database uno solo, convertendolo in altri linguaggi e adattandolo ad altre piattaforme mi sono trovato nella possibilita’ di sviluppare una applicazione web su MSSql+IIS+ASP e portarla a girare su una piattaforma MySQL+Apache+PHP praticamente senza modificare niente…:-D

Quindi, mentre il $MegaApplicativoGlobale ha continuato a crescere, acquisire nuovi arti e teste e perdendone altrettanti come un’Idra geneticamente modificata ogni qualvolta uno dei $personeInAltoConAltoPotereDecisionale gli desse uno sguardo, ho proseguito i miei esperimenti Ajax-oriented portando il mio personale ‘framework’ a una maturita’ tale che mi ha permesso di utilizzarlo per sviluppare un discreto gestionale web interamente ‘web 2.0′, installato al cliente pochi giorni fa (sulla rete interna, nonsu internet, sia ben chiaro!) senza che fino ad ora il cliente suddetto segnalasse problemi di sorta (mai dire mai!).

In questo fine settimana, trovandomi un po’ di tempo libero e voglia di spippolare ho preparato un semplice sistema di gestione dei Trouble Tickets che ho in programma di far utilizzare in futuro ai miei ‘clienti’, sempre basato su quello che ormai sono solito identificare come KAjaxFramework: la K in questione non ha niente a che vedere con il ben noto KDE, e’ semplicemente una naming policy che utilizzo per battezzare le mie creazioni, retaggio di una adolescenza bruciata su internet e per la precisione su IRC, sfoggiando un nick molto l33t avente come iniziale proprio la lettera K.

Il KTroubleTicketSystem, effettivamente non piu’ che una demo delle potenzialita’ dell’ancora acerbo framework, lo potete trovare seguendo questo link (ho creato un ‘account cliente’ di test, potete accedere utilizzando ‘test’ come user e pass), mentre se avete abbastanza fegato, potete dare uno sguardo ai sorgenti del KAjaxFramework scaricandoli da qui, ma vi avverto: NON esiste ancora documentazione, i commenti sul codice sono pochi e confusi.

Per farla breve, il metodo di sviluppo e’ abbastanza semplice:

• Realizzare i vari ‘form’ in html+css, avendo cura di posizionare dei <div> come placeholder nei punti in cui dovranno apparire componenti legati ai dati generati dal substrasto javascript
• Realizzare una home page che conterra’ le interfacce sviluppato al punto precedente sempre con il metodo dei <div> utilizzati come ’segnaposto’
• Caricare (lato client) con la funzione loadForm del framework i form e popolarli con i dati pescati dal database utilizzando le funzioni preposte (funzioni che e’ possibile utilizzare anche per la procedura inversa).

Probabilmente e’ molto piu’ facile da vedere all’opera che da spiegare…il KTroubleTicketSystem e’ li apposta…:-)
Quando riusciro’ a trovare il tempo necessario a ripulire il codice, scrivere la documentazione e sopratutto realizzare un sistema decente di sicurezza (se mal configurato puo’ permettere ad un utente con buoni skills di trovare il modo di modificare i dati sul DB scavalcando senza colpo ferire eventuali controlli) probabilmente registrero’ il progetto su SourceForge, ma fino a quel momento prendetelo come un semplice ‘esercizio di stile’.

E’ passato qualche mese da quando scrissi il primo post riguardante ATLAS, il framework sviluppato da Microsoft per aggiungere funzionalità asincrone ad ASP.NET.

Il progetto è progredito, ha perso il codename ATLAS per trasformarsi semplicemente in ASP.NET AJAX.

Nella HomePage del progetto è possibile visionare alcuni ‘videocorsi’ di sviluppo con asp.net ajax: nel primo viene messa in luce la semplicità di conversione di una normale applicazione asp.net a una basata su ajax.
Una volta creato il progetto utilizzando l’apposito template, si può sviluppare l’applicazione seguendo le direttive classiche di asp.net, salvo poi ‘racchiudere’ le parti che dovranno essere aggiornate in maniera asincrona all’interno di appositi tag.

Gli altri video riguardano problematiche e dimostrazioni piu’ specifiche: utile e interessannte la serie "How Do I".

Mi riaggancio ai miei precedenti post (questo e questo) riguardanti la possibilità da ASP di convertire un recordset in un documento XML da far poi interpretare al substrato Javascript utilizzato dalle applicazioni AJAX.

SQL Server 2005 semplifica ancora di più le operazioni: la conversione in XML è eseguita infatti direttamente dal motore SQL, basta aggiungere alla fine della query il costrutto FOR XML, esempio:

SELECT * FROM ORDINI FOR XML AUTO

La parola chiave AUTO definisce la modalità di output del documento.

Le modalità di output disponibili sono le seguenti:

AUTO: SQL Server scrive la riga in nodo dello stesso nome della tabella, e i valori delle colonne come attributi.
Nel caso nella query siano presenti join con altre tabelle, l’output risulterà nidifcato, senza la possibilità di controllare la nidificazione, tuttavia con la possibilità di fare in modo che i valori delle colonne vengano restituiti come elementi anzichè come attributi, specificando l’opzione ELEMENTS:

SELECT * FROM ORDINI FOR XML AUTO,ELEMENTS

RAW: Produce un ouput con il nodo corrispondente alla riga chiamato sempre ‘row’ e non si occupa di nidificare le tabelle in join.
L’opzione ELEMENTS sortisce lo stesso effetto della modalità AUTO.

EXPLICIT: Comporta una formattazione particolare della query, che deve rispettare i seguenti requisiti:

• La prima colonna deve essere un numero di TAG definito
• La seconda colonna un numero di PARENT definito.

Quest’ultima modalità è senz’altro la piu’ difficile da ottenere, ma di sicuro la piu’ potente e precisa in fatto di formattazione finale.

A breve dedicherò un post esclusivamente a questa modalità.

Con l’intruduzione nelle API delle funzioni di Geocoding, il servizio di mapp online di Google e’ diventato ancora piu’ semplice da utilizzare: una vera manna per i programmatori!

In questo articolo illustro brevemente un metodo estremamente semplice (e grezzo) per caricare in maniera asincrona una serie di marker sulla mappa, utilizzando javascript e un piccolo script ASP, richiamando i dati da un database.

Per prima cosa, richiediamo a google una Api Key per utilizzare il servizio: http://www.google.com/apis/maps/signup.html (io ne ho richiesta una per il sito http://127.0.0.1, in modo da poter sviluppare comodamente in ambiente di test) e includere nella pagina il riferimento alle Google Api:

<script src="http://maps.google.com/maps?
file=api&v=2&key=KEY_GENERATA"
type="text/javascript">
</script>

Prossimo passo e’ richiamare le funzioni necessarie alla creazione della mappa, quindi creiamo subito sulla nostra pagina un <DIV> destinato a contenerla

<div id=”mappa” style=”width: 500px; height: 300px”></div>

e un file .js contenente le funzioni a noi necessarie che includeremo nella pagina.

La prima funzione da realizzare sara’ giustamente quella destinata alla creazione della mappa:

var map;

 

function map_create(elemento) {
map=new GMap2(document.getElementById(elemento));
map.setCenter(new GLatLng(41.895466,12.482323),10,G_NORMAL_MAP);
map.addControl(new GMapTypeControl());
map.addControl(new GLargeMapControl());
mapmade=true;
}

…dove elemento sara’ l’ID del <DIV> creato precedentemente. (la mappa viene automaticamente centrata sulla citta’ di Roma con la funzione setCenter).

Ora scriviamo un piccola funzione che ci permettera’ di creare comodamente markers sulla mappa partendo direttamente da un indirizzo, calcolando autonomamente le coordinate di geomapping:

function AddMarkerFromAddress(address, fumetto, titolo) {

var geocoder = new GClientGeocoder();
geocoder.getLatLng(address,
function(point) {
if (!point) {
alert(address + ” not found”);
} else {
var marker = new GMarker(point);
GEvent.addListener(marker, “click”, function() {
marker.openInfoWindowHtml(fumetto);
});
map.addOverlay(marker);
}
}
);

}

(dove address contiene l’indirizzo al quale creare il marker, fumetto il testo, anche HTML, contenuto appunto nel fumetto e titolo l’eventuale titolo del fumetto).

A questo punto non ci rimane che prelevare la lista degli indirizzi dal database e richiamare n volte la funzione AddMarkerFromAddress.

Inanzitutto realizziamo una pagina ASP che accetti in ingresso una query e restituisca una lista dei dati ottenuti eseguendo la query stessa:

<%

response.addHeader “Pragma”, “no-cache”
response.addHeader “Cache-Control”, “must-revalidate”
response.addHeader “Cache-Control”, “no-cache”
response.addHeader “Cache-Control”, “no-store”
Response.AddHeader “Expires”, 0

set con = Server.CreateObject (“ADODB.connection”)
Con.Open Application(“Connessione_Database”)

sql = request(“query”)
set rs = con.Execute(sql)

risultato = “”

do until rs.eof

for i = 0 to rs.Fields.Count – 1

Response.Write rs(i)
if (i < rs.Fields.Count – 1) then Response.Write “, “

next

Response.Write VbLf

rs.movenext
loop
%>

E’ necessaria in seguito del codice Js che si occupi di caricare i dati dalla pagina:

function GetSQLList(query) {
var xmlhttp = getXMLHttpRequestInstance();
if(!xmlhttp) {
alert(“Il browser non supporta l’oggetto XMLHttpRequest”);
return false;
}
var ReturnValue = “0″;

query = escape(query);

xmlhttp.open(“GET”, “make_query_list.asp?query=”+query,false);
xmlhttp.send(null);
if (xmlhttp.status==200) {
ReturnValue = xmlhttp.responseText;
} else if (xmlhttp.status==404) {
alert(“[ERRORE] l’URL non esiste!”);
} else {
alert(“[ERRORE] errore non gestito (” + xmlhttp.status + “)”);
}
return ReturnValue;
}

Ultimo passo, mettere insieme il tutto:

function LoadMarkersFromQuery (query) {
var lista=GetSQLList(query);
var array_lista = lista.split(“\n”);
for (i in array_lista) {
if (array_lista[i] != “”) {
AddMarkerFromAddress(array_lista[i], array_lista[i], array_lista[i]);
}
}
}

Per caricare i marker quindi, bisognera’ semplicemente (dopo aver creato la mappa con la funzione scritta in precedenza) richiamare la funzione LoadMarkersFromQuery passando come parametro il codice SQL necessario al reperimento dei dati degli indirizzi, es:

LoadMarkersFromQuery(’select via, numero, cap, comune, stato from indirizzi’);

I miei continui esperimenti con AJAX portano continuamente alla nascita di nuove ‘follie’.

L’ultima riguarda una inconsueta mescolanza tra Javascript, ASP ed SQL.

Lo scenario e’ questo: in un progetto ASP+MSSQL ho necessita’ di creare dinamicamente con Javascript svariati elementi (in particolare tabelle e combobox), popolandoli con dei dati presenti sul database.
Il dover creare continuamente nuove pagine ASP per estrapolare i dati, e altre per salvarli mi rallenta di molto il lavoro.

A questo punto l’idea: perche’ non realizzare una pagina ASP ‘generica’, alla quale passare semplicemente la query da eseguire, farmi restituire esclusivamente i dati e processarli con Javascript?

La struttura partorita dalla mia mente malata e’ quindi cosi’ costituita:

1. Una pagina ASP, che accettera’ in ingresso (anche con una semplice chiamata GET) una query, la eseguira’ sul database e restituira’ i dati sotto forma di XML.
2. Una classe Javascript che si occupera’ di prelevare l’XML, processarlo ed estrarre i dati
3. I dati cosi’ ottenuti verranno poi utilizzati da altre funzioni in Js che si occuperanno di creare gli elementi della pagina (Tabelle, ComboBox ecc..).

Partiamo quindi dal codice ServerSide:

SQL2XML.ASP

<%
set con = Server.CreateObject ("ADODB.connection")
Con.Open Application("Connessione_al_DataBase")

sql = request("query")
set rs = con.Execute(sql)

Dim oDOM
Set oDOM = Server.CreateObject("MSXML2.DOMDocument")
oDOM.async = False
rs.Save oDOM, 1 ‘adPersistXML

 

Dim oXSL
Set oXSL = Server.CreateObject("MSXML2.DOMDocument")
oXSL.async = False
oXSL.load Server.MapPath("ADOGeneric.xsl")
Response.Write "<XML id=’xmlData’ name=’xmlData’><root>" & vbCrLf
Response.Write oDOM.transformNode(oXSL)
Response.Write "</root></XML>"

%>

Il funzionamento e’ semplice: estrae la query da eseguire dalla QueryString, effettua la connessione al DataBase, raccoglie i dati, li converte in XML e li formatta utilizzando lo StyleSheet XML ADOGeneric.xsl.

ADOGeneric.xsl

<?xml version=’1.0′?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:z="#RowsetSchema">
       <s:Schema id="RowsetSchema"/>
<xsl:output method="xml" omit-xml-declaration="yes" />
<xsl:template match="/">
       <xsl:apply-templates select="//z:row"/>
</xsl:template>

<xsl:template match="z:row">
       <xsl:text disable-output-escaping="yes">&lt;row&gt;</xsl:text>
               <xsl:for-each select="@*">
                      <xsl:text disable-output-escaping="yes">&lt;</xsl:text>
                       <xsl:value-of select="name()"/>
                       <xsl:text disable-output-escaping="yes">&gt;</xsl:text>
                       <xsl:value-of select="."/>
                       <xsl:text disable-output-escaping="yes">&lt;/</xsl:text>
                       <xsl:value-of select="name()"/>
                       <xsl:text disable-output-escaping="yes">&gt;</xsl:text>
               </xsl:for-each>
       <xsl:text disable-output-escaping="yes">&lt;/row&gt;</xsl:text>
</xsl:template>
</xsl:stylesheet>

La riformattazione utilizzando lo stylesheet rende piu’ comodo il successivo processo di interpretazione dei dati tramite Javascript.

Mettiamo ora mano al codice ClientSide:

Query2Table.js

/*
* Creazione tabella da query
* @param    Query    Stringa contenente la query da inviare al server
* @param    elemento       ID dell’elemento della pagina che conterrà la tabella
*/

function SQL2Table(query, elemento)
{
 
 if (document.implementation && document.implementation.createDocument)
 {
  xmlDoc = document.implementation.createDocument("", "", null);
  xmlDoc.onload = createTable(elemento);
 }
 else if (window.ActiveXObject)
 {
  xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
  xmlDoc.onreadystatechange = function () {
   if (xmlDoc.readyState == 4) createTable(elemento)
  };
  }
 else
 {
  alert(‘Your browser can\’t handle this script’);
  return;
 }
 query = query.replace(" ","+");
 xmlDoc.load("SQL2XML.asp?query=" + query);
}

function createTable(oggetto)
{
 var x = xmlDoc.getElementsByTagName(‘row’);
 var newEl = document.createElement(‘TABLE’);
 newEl.setAttribute(‘cellPadding’,5);
 var tmp = document.createElement(‘TBODY’);
 newEl.appendChild(tmp);
 var row = document.createElement(‘TR’);
 for (j=0;j<x[0].childNodes.length;j++)
 {
  if (x[0].childNodes[j].nodeType != 1) continue;
  var container = document.createElement(‘TH’);
  var theData = document.createTextNode(x[0].childNodes[j].nodeName);
  container.appendChild(theData);
  row.appendChild(container);
 }
 tmp.appendChild(row);
 for (i=0;i<x.length;i++)
 {
  var row = document.createElement(‘TR’);
  for (j=0;j<x[i].childNodes.length;j++)
  {
   if (x[i].childNodes[j].nodeType != 1) continue;
   var container = document.createElement(‘TD’);
   var theData = document.createTextNode(x[i].childNodes[j].firstChild.nodeValue);
   container.appendChild(theData);
   row.appendChild(container);
  }
  tmp.appendChild(row);
 } 
 
 document.getElementById(oggetto).appendChild(newEl);
}

La funzione SQL2Table si occupa, con il solito meccanismo cross browser di richiamare la pagina ASP creata in precedenza passandogli la query da eseguire, estraendo i dati e passandoli alla seconda funzione (createTable) insieme all’ID dell’elemento della pagina che conterra’ la tabella (un <p> o un <div>).

createTable processera’ l’XML ottenuto da SQL2Table, creando  la tabella con nella prima riga le intestazioni contenenti i nomi dei campi estratti dalla query, ‘riversando’ poi il tutto nell’elemento della pagina specificato.

Volendo testare il corretto funzionamento del nostro script, possiamo realizzare un semplice documento HTML:

Test.htm

<SCRIPT LANGUAGE=javascript src="Query2Table.js"></SCRIPT>

<p id=tabella name=tabella></p>

<INPUT type="button" value="Crea Tabella" id=button1 name=button1 onclick="javascript:SQL2Table(’select * from impiegati’,'tabella’);">

Come si puo’ evincere dal codice, tutto cio’ comporta sicuramente una maggiore rapidita’ nella fruizione di dati dal DB, ma include serie conseguenze dal lato della sicurezza:
premetto che questa che sto implementando questa struttura all’interno di un progetto destinato ad una intranet, quindi in mano a personale ‘fidato’ (lungi da me metter un accrocchio del genere su internet), ma nulla toglie che un utente malizioso e un po’ piu’ skillato possa fare il bello e il cattivo tempo sul database.

La soluzione da me qui riportata deve essere intesa solo come un proof of concept, niente quindi che possa essere utilizzando in un progetto reale, a meno che non si implementi (come sto gia’ facendo) un meccanismo di comunicazione ’sicuro’ tra client e server, magari criptando in qualche modo la stringa contenente la query da eseguire.