Metodi di scambio dati

Metodi di scambio dati postato il 05/01/2009 02:40:13 nel forum programmazione, open source e hosting

Mi scuso per il titolo sicuramente inappropriato ma non riuscivo a trovare una sintesi "da titolo" adatta all'argomento da trattare.
In breve in un thread sulla Struttura a skin di new world (https://www.gdr-online.com/readforum.asp?id=82415&pag=2 ↗) è venuta fuori una discussione interessante su quale sia il metodo corretto, più veloce ed efficiente per trasmettere dati da server a browser.
Per riassumere, new world, come altri gdr, usa ajax semplicemente per fare chiamate asincrone a programmi php che restituiscono direttamente html già formattato.
Shanks1 ha, a mio avviso giustamente, detto che così è inutile -tanto vale un iframe o simili- perchè veniva a mancare l'idea stessa di utilità di AJAX.
Quindi proponeva di usare linguaggi per scambiare dati del tipo di xml, json et similia e di lasciare poi a javascript il compito di impaginare il tutto (lui suggeriva l'uso della funzione nativa di prototype chiamata Template, ma mi stuzzica personalmente l'idea di usare il DOM).
La questione la trovo particolarmente interessante, perchè ho da poco sviluppato una ancora molto rudimentale chat in ajax e json ma sono rimasto colpito dal potenziale che potrebbe avere applicato all'intero gdr.
Vorrei sentire il parere di più persone, allargando la discussione e avendola posta in un apposito topic.
grazie :)

05/01/2009 08:39:24

Questo argomento e relativa spiegazioni ed approfondimenti interesserebbero anche a me, che da secoli cerco di affrontare Ajax con scarsissimi risultati ç_ç

05/01/2009 10:09:55 e modificato da clemence il 05/01/2009 10:15:55

Chiedo scusa se rispondo a shanks da qua ignorando temporaneamente gli altri scritti.

Se il parsing viene fatto da php non risolvi niente! Si ritorna al discorso iniziale: tanto vale usare i frame.

Perchè dici così? Il parsing viene fatto dal php, ma la cosa è settabile banalmente dalla presenza o meno di una ipotetica variabile che chiuda il giro in quel modo.

Di base il php scrive un xml, se (e solo se) viene passata una data codifica si può effettuare una trasformazione xslt, altrimenti resta un xml puro che può essere gestito a piacimento anche da js, flash o quel che si vuole.

Di base la scrittura del php non viene quindi più rimessa in discussione (a meno di allargamento dei dati necessari o modifica degli stessi), la trasformazione parsificata è solo una comodità per non far fare il lavoro di trasformazione in xhtml a js.

Recupero la logica base:

<?php

$xml = new DOMDocument;


//cicli vari per generare l'xml che ci serve




/* solo se necessario opera una trasformazione con l'xsl... */

if($isNeeded)
{
$xsl = new DOMDocument;

/* volendo si può passare una variabile per indicare il foglio di stile xsl che verrà applicato */

$xsl->load('miotrasformatore.xsl');


$proc = new XSLTProcessor;
$proc->importStyleSheet($xsl);

echo $proc->transformToXML($xml);
}

/* ...altrimenti stampa l'xml */

else
{
echo $xml->saveXML()
}

?>

Quindi di fatto la parte di codice opzionale (in grassetto) è presente solo alla fine del codice, è decisamente ridotta e nulla toglie al senso della parte precedente.

Si può quindi scegliere tra il dato puro o già trasformato in xhtml per uso xhtml appunto.

non riesco a cogliere la differenza che passa tra fare una cosa del genere o creare i template in prototype (esempio che hai citato tu) e farlo applicare da js.

Il dato puro c'è in entrambi i casi, ma così hai eventualmente il trasformatore naturale più adatto alla bisogna

05/01/2009 11:50:53

darkside of breakfast ha scritto:
Shanks1 ha, a mio avviso giustamente, detto che così è inutile -tanto vale un iframe o simili- perchè veniva a mancare l'idea stessa di utilità di AJAX.

Questa parte non la capisco, il senso di ajax, tra i tanti, era anche quello di levare i frame dalle palle, quindi anche un output diretto in xhtml può avere senso se il dato ottenuto è direttamente un testo visualizzabile.

Discorso diverso se il risultato della chiamata debba essere un oggetto che poi, ragionato da js, avrà un utilità differente o non soltanto di semplice testo.

In quel caso probabilmente json è la scelta più appropriata per il passaggio dei dati.

Se con i dati vogliamo uscire in xml (per un eventuale riuso del codice in possibili contesti non xhtml diretto) consiglio sempre una trasformazione via xslt (client o server a seconda dei gusti) invece di una navigazione dei nodi via js e una loro trasformazione tramite questo.

xslt è stato inventato apposta per questo scopo in fondo :)

Se usare un json o un output xml->xhtml o xhtml diretto dipende dal caso volta per volta, ma spesso e volentieri (per fortuna e per semplicità) si può operare con xml->xhtml o xhtml diretto a meno di non voler effettuare esercizi di stile :)

05/01/2009 13:24:09

Ehm, arrivo tardi :D
oorazoroo è stato più che esauriente penso :P

05/01/2009 13:33:42 e modificato da clemence il 05/01/2009 13:34:19

Veramente non ho mai detto che con ajax intendo richiamare una intera pagina e stamparla in un div.

Ho detto che recupero i dati che mi servono e li metto in un div o dove mi servono.

Se mi servono in un div probabilmente avranno bisogna di una data formattazione xhtml aggiuntiva e in quel caso faccio prima, eventualmente, a darla direttamente all'output (xhtml diretto) o, se ho dubbi su tutte le destinazioni future, in xml trasformato in quel caso da xslt in xhtml.

05/01/2009 14:07:15

joshi ha scritto: [quote]clemence ha scritto: Veramente non ho mai detto che con ajax intendo richiamare una intera pagina e stamparla in un div.

Ho detto che recupero i dati che mi servono e li metto in un div o dove mi servono.

Se mi servono in un div probabilmente avranno bisogna di una data formattazione xhtml aggiuntiva e in quel caso faccio prima, eventualmente, a darla direttamente all'output (xhtml diretto) o, se ho dubbi su tutte le destinazioni future, in xml trasformato in quel caso da xslt in xhtml.

Farlo lo puoi fare, ma si chiama "bloating" :)[/quote]

?

05/01/2009 15:02:13

shanks1 ha scritto: Ehm, arrivo tardi :D
oorazoroo è stato più che esauriente penso :P

beh, raz ha anche detto che preferisce usare php semplice per la maggior parte ed usare json solo per determinati tipi di applicazioni...
Mentre tu sul grande blu hai sviluppato tutto in json.
Ed il mio dubbio è proprio su questo tipo di lavori...
Mi chiedo se il lasciare ad un linguaggio lato-client (javascript in questo caso) il compito di impaginare i dati spuri passati dal lato-server, non appesantisca eccessivamente il lavoro dell'utente rallentandone così la navigazione.

05/01/2009 16:53:57

Se si tratta di impaginare, oramai, con le potenze di calcolo che si hanno su qualsiasi pc attualmente in commercio, non ci sono problemi.
L'unico problema sussiste nell'interpretazione di json da parte di internet explorer (ammetto piuttosto lentino). Basta fare a meno di usare json per il più comune xml, in tal caso non si notano rallentamenti: basta che apriate il task manager per capuire quante risorse sta succhioando il vostro browser.
Ad ogni modo, json non sarà più un problema per internet explorer a partire dalla prossima versione IE8.
Nessuno costringe a usare json, allo stesso moso potete usare xml, il risultato è che non vengono subiti rallentamenti da parte del browser visibili a un utente umano.

07/01/2009 18:26:54

Quando parlo di ultima generazione, intendo Pentium 4, uscito nel lontano 2001 :)