Interazione PHP e Javascript

[andr3a]

up

[Fredx]

Originariamente inviato da andr3a
Essendo la conversione verso PHP in formato serialize molto veloce, penso di tenere questa ma in ricezione dati stò valutando JSON.

Bene, questo mi fa piacere visto che ho difeso JSON per un bel po'

1 - JSON non permette l'invio di array come hashtable o cmq con chiavi associative, è giusto ? (bella cappella, la serialize faceva anche questo) ... e nemmeno l'invio di classi create in JS giusto?

prima dovrei capire cosa intendi
Passare un array associativo a javascript non ha molto senso, visto che javascript di fatto non supporta gli array associativi. E con "inviare una classe" cosa intendi?
In ogni caso JSON ha un metodo per scrivere gli oggetti:

var frutto = { "nome" : "mela", "colore" : "rosso" };

Di fatto, questo è un oggetto, con le proprietà nome e colore (frutto.nome e frutto.colore).
Sostanzialmente però è più simile ad un array associativo che ad un oggetto, visto che non ci sono metodi...
Volendo comunque possono essere inseriti metodi, mettendo al posto del valore una funzione.

var frutto = { 
"nome" : "mela",
"colore" : "rosso",
"mangia" : function() {
   // fai qualcosa
}
};

2 - visto che tanti convertono semplicemente le variabili da JSON, seppur possa sembrare un doppio passaggio, stò lavorando su una conversione da php a json tramite il formato serializzato ... tipo echo JSON_from_Serialized(serialize($variable)); per avere un output compatibile con JS su stringhe serializzate o pre-serializzate ... questo potrebbe avere senso?

boh... vorrebbe dire che i dati vengono convertiti due volte...
se fai una classe generica che converte in json qualsiasi variabile, per convertirne una serializzata basta deserializzarla.
se invece è + semplice convertirlo dal formato serializzato, allora potrebbe andar bene... non penso sia molto più lento visto che serialize è veloce... e se guardi la classe JSON di php penso che han fatto un sacco di controlli per capire il tipo delle variabili... quindi si forse è meglio partire da stringhe serializzate

3 - se si, potrebbe far comodo una classe che converte da php_serializzata a JSON e viceversa, tipo da JSON a php_serializzata ? (vantaggi: nessuna libreria richeista, si sfrutta una funzione veloce quale è serialize e quanti più stratagemmi possibili per evitare problemi di conversione come lentezza o altro)

nel caso in cui dicevo prima, sì

[andr3a]

Originariamente inviato da Fredx
Bene, questo mi fa piacere visto che ho difeso JSON per un bel po'

JSON è un metodo valido di passaggio dati ma ha grandi limiti per lo stesso JavaScript ... ora ti dico perchè

Originariamente inviato da Fredx
Passare un array associativo a javascript non ha molto senso, visto che javascript di fatto non supporta gli array associativi.

questo non è vero poichè in javascript un array è come in PHP se non meglio, nel senso che può avere chiavi intere o chiavi di tipo stringa e qualora fossero stringhe numeriche rimarrebbero di tipo stringa e non numeriche come avviene invece in php.
In poche parole gli array di PHP e di JavaScript sono estremamente simili, non a caso ho sempre preferito la mia classe PHP_Serializer piuttosto che JSON per lo scambio dati.

Originariamente inviato da Fredx
E con "inviare una classe" cosa intendi?
In ogni caso JSON ha un metodo per scrivere gli oggetti:

Di fatto, questo è un oggetto, con le proprietà nome e colore (frutto.nome e frutto.colore).
Sostanzialmente però è più simile ad un array associativo che ad un oggetto, visto che non ci sono metodi...
Volendo comunque possono essere inseriti metodi, mettendo al posto del valore una funzione.

con la mia PHP_Serializer puoi inviare classi da e verso PHP.

se in javascript hai un'oggetto Pippo

function Pippo(){
this.name = "pippo";
};

ed una
var p = new Pippo();

puoi serializzare questo dato che in automatico sarà visto come un O, di oggetto PHP dove se in php hai
class Pippo{
var $name = "";
}
una volta deserializzato hai i parametri interni allineati ergo passi anche oggetti complessi, mentre gli oggetti, intesi come array associativi o numerici, vengono trasferiti come tali dove un for(var a in myObj) funzionerebbe tale quale ed i metodi degli oggetti rimarrebbero invariati.

Per dirla in poche parole, la serialize converte da e verso JavaScript classi => new function Name(){} con parametri privati, protected o public trasferiti, array => new Array, come associativi o numerici, più tutte le altre variabili mentre JSON non ha questa capacità, ergo è molto limitato rispetto l'invio e ricezione serializzato.

Originariamente inviato da Fredx
boh... vorrebbe dire che i dati vengono convertiti due volte...
se fai una classe generica che converte in json qualsiasi variabile, per convertirne una serializzata basta deserializzarla.
se invece è + semplice convertirlo dal formato serializzato, allora potrebbe andar bene... non penso sia molto più lento visto che serialize è veloce... e se guardi la classe JSON di php penso che han fatto un sacco di controlli per capire il tipo delle variabili... quindi si forse è meglio partire da stringhe serializzate

la serialize è compilata ed abbastanza veloce, dai miei tests la JSON compilata di Omar Kilami è una bomba in termini di prestazioni ma non ha la ricorsione (altra enorme pecca di JSON) mentre la versione PEAR fa veramente schifo in termini di prestazioni, "ammazza il server".

La classe da serializzata a JSON lavora su un intero ed una stringa, non deve effettuare alcun controllo poichè questo è già stato fatto dalla serialize e se la stringa è una serializzata del PHP non serve a niente verificare che a{} sia array ed i intero, per intenderci ... quindi per ora sono stra soddisfatto delle prestazioni, lavora con variabili innestate senza problemi ed il passaggio serialize => JSON è velocissimo.

Più lento invece il passaggio da JSON a serialize, per una sfilza di motivi validi, primo tra tutti, la lentezza della nota funzione di conversione da JavaScript a formato JSON, dove la mia PHP_Serializer si è dimostrata molto più veloce su variabili complesse, senza problemi di oggetti innestati o altro però a questo punto diventa macchinoso lo scambio, non perchè non si possa fare in modo semplice, semplicemente perchè la serialize ha molte più possibilità di JSON di inviare dati utili, funzioni intese come classi o altro, mentre JSON, come ho detto, è molto limitato da questo punto di vista.

Per finire ieri ho uploadato l'ultima versione della PHP_Serializer, mi piacerebbe avere riscontri con un browser Safari se possibile, grazie

[skidx]

ma il problema con le stringhe multibyte non era dato proprio dalla serialize del php che conta i byte invece dei caratteri?

Non ho chiaro in che modo JSON risolverebbe, se comunque gli dai in pasto una stringa serializzata, quindi già col "vizio di forma".

[andr3a]

Originariamente inviato da skidx
ma il problema con le stringhe multibyte non era dato proprio dalla serialize del php che conta i byte invece dei caratteri?

problema in parte risolto da tempo e migliorato in gestione in quest'ultima release della PHP_Serializer ... ma per forza di cose bisogna andare a cercare di riprodurre quella length in riconversione "fasulla" tramite javascript, quindi con stringhe da migliaia di caratteri da problemi.

Originariamente inviato da skidx
Non ho chiaro in che modo JSON risolverebbe, se comunque gli dai in pasto una stringa serializzata, quindi già col "vizio di forma".

JSON non ha length di stringhe, sono racchiuse tra apici, fine.
Questo comporta una semplicità spaventosa in conversione da serializzata a json perchè basta schiaffare la length di PHP, giusta o sbagliata che sia, tra apici e fare un str_replace dei caratteri per javascript, tra cui eventuali altri apici di stringa.

questo: s:5:"te"st";
in JSON è così: "te\"st" quindi JS lo divora con destrezza, mentre PHP è agevolato in conversione verso JSON, un pò meno da JSON a PHP.

La classe che ho appena finito (ma che devo debuggare) fa questo:

2 metodi:
- getJson
- getPhp

il primo converte una stringa serializzata in modo compatibile con JSON, con tanto di nested vars e compagnia bella

il secondo converte una stringa JSON in una variabile PHP, non faccio tornare la corrispettiva serializzata perchè non è detto che serva sempre quindi se non dovesse servire farei 2 inutili passaggi in più ... return serialize($result); dove se uno ha bisogno di quella var deve rifare
$var = unserialize($classe->getPhp($json)); e questo è poco sensato ...
l'invio invece richiede la serialize ovviamente, qualora la stringa non dovesse essere presa da un db in formato già serializzato dove non avrebbe senso, allo stesso modo, un doppio passaggio. Se invece non è serializzata basta farlo al volo in chiamata metodo:
$json = $classe->getJson(serialize($var));


la classe altro non fa che un banale switch, velocissima quindi e dovrebbe uccidere PEAR, dove secondo me hanno fatto un errore nel non valutare la semplicità rappresentata da una var PHP serializzata ... ma farò dei benchmark a riguardo.

Vi sembra comunque interessante anche se le possibilità di scambio dati non sono al livello della PHP_Serializer ?

[Fredx]

allora, confermo la mia ignoranza non sapevo che in js esistessero gli array associativi

tornando in tema: sì, parlavo della classe PEAR che ho visto sia dai tuoi test che da alcuni che ho effettutato io è lentissima. mentre scrivevo la risposta precedente mi era proprio venuto in mente come una variabile serializzata pottesse essere più semplice da convertire nel formato JSON

per quanto riguarda il resto hai pienamente ragione, JSON è più limitato del serialize, però per ciò che ho provato a fare io con AJAX non mi è mai servito niente di più complesso, quindi ho continuato a utilizzarlo. Certo con JSON forse non riuscirai mai a fare qualcosa come AJSHP, però non è detto che serva sempre qualcosa di così complesso/completo.

Secondo una classe che sia in grado di passare da serialize a json e viceversa potrebbe essere utile... in questo modo gestisci con javascript un formato a lui comodo, e la stessa cosa in PHP.

Ultima cosa: parli spesso di inviare i dati da php a javascript, ma non mi viene un esempio in ciò possa essere utile... non basta inviare i dati semplicemente da un form via GET o POST, come si fa di solito?

[andr3a]

eccomi di nuovo qua

intanto rispondo a Fredx:
1 - nel frattempo la classe PEAR è stata aggiornata ... con ottimi miglioramenti in termini di prestazioni, resta un disastro confrontata alla funzione serialize/unserialize o a quella di omar Kilami. C'è da dire però che quella PEAR fa anche variabili innestate mentre quella di Omar Kilami, compilata e velocissima, mi sembra proprio di no, perlomeno non la versione da me testata, tragedia !!!

2 - gli applicativi in AJAX sono il presente e parte del futuro, avere classi da gestire allo stesso modo lato server e lato client è la kill-app del momento, non a caso i frameworks più complessi sfruttano questo principio per le interazioni ma tutti si basano solo sulle classi server ... mentre averne analoghe sul client ... beh, non ti dico che bello che è detto questo la serialize non deve gestire per forza cose complesse ma rende sempre più simili le var in php e js, array associativi e/o numerici ed oggetti con la O maiuscola, con tanto di nome, senza una stdClass inutile rilasciata da JSON ma una classe Pippo, esistente e reale sia sul client che sul server ... e se sul client non c'è, la mia serialize la crea in automatico

3 - l'invio dati da PHP a JS è estremamente utile per sfruttare ajax, invece di rilasciare un output rilasci una serializzata come risultato di operazioni oppure una JSON .... poco importa, l'importante è che ajax non debba caricare pagine intere ma solo dati utili, JSON o serialize, sennò tanto varrebbe non usare ajax




torno in generale ...
le prestazioni buone del convertitore stringa serializzata => JSON non sono realmente così buone, ho fatto benchmarks per confrontare la nuova PEAR con la mia classe ed alla fine sono giunto alla conclusione che effettivamente ha poco senso perchè bisogna riparsare una stringa piuttosto che una semplice variabile con metodi o funzioni apposite.
Conclusione ? Ho scritto unaclasse JSON per i fatti miei, probabilmente non efficace quanto quella PEAR ma decisamente più veloce, sia in conversione verso JS sia in conversione da JSON a variabile PHP ... ma non sono rimasto comunque soddisfatto ne delle prestazioni sul server ne di quelle sul client, nonchè dei limiti stessi di JSON che mi rompono non poco le scatole.

Per concludere ho rimesso mano alla PHP_Serializer sempre non contento dei suoi limiti intrinsechi in conversione utf8.

Per finire ho appena finito di testare una nuova versione della PHP_Serializer che supporta nativamente utf8, ovvero se ne frega altamente del tipo di stringa poichè il motore di conversione stringhe da e verso PHP funziona sempre allo stesso modo ed a quanto pare funziona bene.

quesito per tutti
preferite una classe javascript un pò più lenta in conversione ma con tempi comunque accettabili oppure non vi importa dell' UTF-8 e preferite scegliere se o quando usarlo a favore di prestazioni "record" nella versione, per l'appunto, non UTF-8 ???

il problema è questo:
la nuova serializer in JS è basata sul fatto che l'occorrenza dei caratteri di fine stringa "; non sia elevata e ad ogni occorrenza verifica se la length da punto N a punto N + caratteri fino a "; è identico al corrispettivo trovato nel pezzo a inizio stringa

s:4:"test";

in questo caso è immediato, ma su una stringa con tante occorrenze di "; è un disastro

s:10:"";";";";";";
questo è un esempio stupido, ma pensate a stringhe pesanti con tanti caratteri o paragrafi, la possibilità di avere N occorrenze di "; diventa critica per la conversione in UTF-8.

Unserialized in 2.293 seconds.
Serialized in 0.12 seconds.
String is the same ? true

questo il risultato della versione attuale con UTF-8 abilitato ... su un' array, $test2, fatto così:

$test1 = utf8_encode(str_repeat('";', 100));
$test2 = array();
for($a = 0; $a < 100; $a++)
	array_push($test2, $test1);

questi i tempi della mia nuova versione demo ...

Unserialized in 0.3 seconds.
Serialized in 0.12 seconds.
String is the same ? true

ovviamente la versione non UTF-8 non ha paragoni rispetto la mia demo poichè i tempi diventano
0
e
0.02

.... quello che non mi piace però è avere un oggetto di conversione sensibile ai dati, preferisco di gran lunga far sudare un pò di più il client ma avere decrementi di prestazioni controllati e non esponenziali, ovvero pari al numero di caratteri, quindi "calcolabili" e non alle occorrenze di un dato, quindi potenzialmente non calcolabili ed in casi estremi critiche ... voi cosa fareste ?

io voto demo auto utf-8 ... ma vorrei sentire altri pareri



scusate il posto prolisso ... ma per me è molto importante

[daniele_dll]

ehm ... hai mai pensato alla possibilità di convertire i caratteri UTF8 in entità html? :master:

[andr3a]

Originariamente inviato da daniele_dll
ehm ... hai mai pensato alla possibilità di convertire i caratteri UTF8 in entità html? :master:

la funzione serialize di PHP non lo fa

quindi dovrei convertire prima di serializzare per poi riconvertire su javascript ... e questo non è automatizzabile ... diciamo che per AJSHP potrebbe andare ma per una generica PHP_Serializer no ... sbaglio ?

[daniele_dll]

puoi serializzare e poi convertire prima di inviare i dati

del resto i caratteri in utf8 iniziano tutti con una fascia di byte ben precisa quindi nel caso si lavori in utf8 puoi benissimo scorrere il contenuto delle stringhe e, una volta trovato, coverti il carattere e il suo successivo nella corrispondente entità html andando ovviamente ad aggiornare la lunghezza dei caratteri presenti nella stringa, ovvero riducendola di 1 (quando a javascript arrivano entità html se non erro queste vengono convertite dal browser in html ... sto parlando da php (server) al client (browser))