Interazione PHP e Javascript

[skidx]

Originariamente inviato da andr3a
cambia la forma, non il problema .... usa tutti gli XML che ti pare, un new Object('test') o new Number() non e' rappresentabile in php e non puo' tornare in js ... quindi XML serve solo ad appesantire parsing e mole di bytes in scambio dati

Forse stiamo guardando la cosa da una prospettiva diversa.
Passare dei dati che non sono rappresentabili nell'altro linguaggio non ha molto senso a prescindere, quale che sia il formato usato nella comunicazione. Esattamente come passare un Resource PHP al javascript, l'esempio che tu hai fatto prima.

Ciò detto, è evidente che lo scambio deve ridursi a un sottoinsieme di tipi comuni a entrambi i linguaggi. XML rende il tutto universale (se domani lo script con cui parlare è Java o Python o Ruby, etc. etc, invece che PHP non devi cambiare niente nel passaggio dati), ciò non toglie che possa essere comodo in certi casi un passaggio di dati in forma compatta.
Io mi focalizzerei soprattutto su quanto diceva Fabio, e cioè sull'ottimizzare soprattutto il lavoro lato server. Guadagnare qualche centesimo di secondo lato client non cambia niente, visto che lo script lato server gira per ogni richiesta, rallentando tutti, mentre lo script lato client gira separatamente per ogni utente e alla singola persona qualche centesimo di secondo non fa alcuna differenza.

[andr3a]

Originariamente inviato da skidx
Forse stiamo guardando la cosa da una prospettiva diversa.
Passare dei dati che non sono rappresentabili nell'altro linguaggio non ha molto senso a prescindere, quale che sia il formato usato nella comunicazione.

esatto,per questo dico che attualmente, considerando questo presupposto, la classe PHP_Serializer è già "perfetta"

Originariamente inviato da skidx
Esattamente come passare un Resource PHP al javascript, l'esempio che tu hai fatto prima.

o passare un new Number() a php ...

Originariamente inviato da skidx
XML rende il tutto universale (se domani lo script con cui parlare è Java o Python o Ruby, etc. etc, invece che PHP non devi cambiare niente nel passaggio dati), ciò non toglie che possa essere comodo in certi casi un passaggio di dati in forma compatta.

fare una classe di serializzazione dove la serializzazione è tipica del php significa fare una classe di serializzazione da e verso php ... quello che dici su XML è giusto, ma qui è completamente OT.
Lo scopo non è fare uno scambio dati, lo scopo è interagire con php e nessun altro

Originariamente inviato da skidx
Io mi focalizzerei soprattutto su quanto diceva Fabio, e cioè sull'ottimizzare soprattutto il lavoro lato server.

mi sono perso questa parte di Fabio ... dove lo diceva e a che proposito ?
il server deve essere il più veloce, il più immediato, non deve sudare il server, bensì il client, altrimenti javascript perde tutti i vantaggi che ha ... non trovi ?

Originariamente inviato da skidx
Guadagnare qualche centesimo di secondo lato client non cambia niente

stai scherzando ?
prima di sfonrare quest' ultima release ne ho fatte 2 che per parsare 1000 records da 4 fields l'uno impiegavano sui 16 secondi ed anche di piu' e mandavano la CPU a 100% per tutta la durata della conversione .... non stiamo parlando di una stringa, stiamo parlando di recordset completi da databse, per dirne una.

Guarda il secondo esempio di questa pagina, impiegava 5 secondi in media, poi grazie a tutte le ottimizzazioni implementate su JavaScript, è diventato quasi real-time (virtualserver balordo a parte ...)
http://www.devpro.it/AJSHP/#example
e il PC non sente alcuna fatica ... ridotto i tempi del 500% ... vedi tu se conta ottimizzare il client, in questo caso, oppure no

Originariamente inviato da skidx
visto che lo script lato server gira per ogni richiesta

ma anche no

Originariamente inviato da skidx
rallentando tutti, mentre lo script lato client gira separatamente per ogni utente e alla singola persona qualche centesimo di secondo non fa alcuna differenza.

fidati, in questo caso è stato FONDAMENTALE ottimizzare quanto più possibile il javascript ... e penso che Fabio te lo possa confermare, i dati non sono pochi, possono esere migliaia, se si vuole fare una cosa scalabile ed utile, altrimenti non ci perdevo 3 giorni tra debug ed ottimizzazioni minuziose sul JS ... un banale try catch piuttosto che un != Function, mi portava via "ore", metaforicamente parlando

[chris]

Originariamente inviato da andr3a
ma anche no

Non so che sistemi usi tu, Andrea, ma mediamente ad un server sono collegati diversi client. Casi in cui il rapporto è uno a uno sono in misura molto minore (pannelli di controllo).

Detto questo è evidente come la parte lato server debba essere quella sottoposta ad una maggiore ottimizzazione dato che le risorse vanno suddivise tra tutti i client che fanno richieste.

Ovviamente è evidente anche che lato client l'implementazione non possa portare via 16 secondi di utilizzo del processore al 100%. Ma skidx parlava di "centesimi di secondo"...

[skidx]

vabbè, tu parli di decine di secondi, io parlavo di guadagnare decine di centesimi, ovvio che risparmiare secondi è doveroso

[skidx]

Originariamente inviato da chris
[...]

mi leggi nel pensiero

[andr3a]

Originariamente inviato da chris
Non so che sistemi usi tu, Andrea

da quando ho partorito AJSHP uso quello

Originariamente inviato da chris
ma mediamente ad un server sono collegati diversi client. Casi in cui il rapporto è uno a uno sono in misura molto minore (pannelli di controllo).

si ma il mio "anche no" era riferito a dover fare una chiamata al server per ogni cosa ... lo scopo del progetto e/o di questa serialize è proprio quello di poter prendere quanti più dati possibili con una sola chiamata (di qui l'ottimizzazione stranecessaria sul client) e gestire quanto più possibile le cose lato client.

AJAX non significa più chiamate al server, AJAX significa delegare il più possibile al client, quindi una gestione in array multidimensionale non è che la devo ricreare ogni volta, faccio una sola chiamata, il server sarà ovviamente ottimizzato ed a quel punto lavoro sulla memoria e sui dati del client, ergo posso evitarmi molte chiamate al server o farne di veramente irrisorie a livello di carico per tempi o prestazioni.

Originariamente inviato da chris
Detto questo è evidente come la parte lato server debba essere quella sottoposta ad una maggiore ottimizzazione dato che le risorse vanno suddivise tra tutti i client che fanno richieste.

questo a prescindere, ed in questo caso più che mai ... come ho già detto. Il server, non fatica così tanto a fare un echo serialize(valore); piuttosto che generare un intero output ... concordi ?

Originariamente inviato da chris
Ovviamente è evidente anche che lato client l'implementazione non possa portare via 16 secondi di utilizzo del processore al 100%. Ma skidx parlava di "centesimi di secondo"...

ragazzi, non è che sono poi cosi' tanto imbecille ... se vi dico che non è stato facile ottimizzare il CLIENT significa che c'ho perso molto più tempo di quello previsto ... non è una cavolata che un try{} catch() per testare se il dato era funzione piuttosto che un data.constructor != Function, implementato grazie al codice di Fabio, sia stata una delle svolte maggiori ... ed ottimizzare al MILLESIMO, credo di averlo già fatto, non ho tolto "solo i secondi" .. ma se potessi ottimizzare un altro millesimo, lo farei di sicuro e non me lo lascerei sfuggire perche' 100, 1000, 10.000 records, voglio poterli inviare e la conversione ha tempi esponenziali.

Quindi si, in questo caso è doveroso togliere anche il millesimo di secondo

Originariamente inviato da skidx
vabbè, tu parli di decine di secondi, io parlavo di guadagnare decine di centesimi, ovvio che risparmiare secondi è doveroso

una linea di codice, spariti i secondi, più tanto altro ancora, quasi quasi vi posto la prima versione, la metà di questa, come codice, 40 volte più lenta, in tutto!

Questo per dire che se devi ottimizzare il client, tanto vale farlo quanto più ti è possibile, oppure non lo fai per niente, o no ?

[Fabio Heller]

Andrea forse non ci siamo capiti: non ritengo fastidioso il prototype (visto che al momento è l'unico modo di programmare object oriented in Javascript) ma neppure mi ci sono affezionato.

il mio dubbio è un altro

come tradurre in PHP

var x = new String('bla bla') ;

oppure

var y = new Number(5) ;

?

Tutti i tipi in Javascript sono oggetti..cosa facciamo?

Meglio mettere un avviso a chi usa la classe ("Attenzione non usare new String('qualcosa'), o new Numer(9)!!! ) oppure fare in modo che le stringhe, i numeri, i booleani etc.etc., in quanto oggetti Javascript perfettamente leciti vengano tradotti nel tipo più vicino possibile in PHP?

Tradurre una stringa in un array non è di sicuro la cosa migliore da fare.

Quindi le soluzioni possibili e alternative sono due
1) prototype
2) estrazione del tipo dal constructor

non userei il typeof, tutto qui...

Inoltre io preferisco tradurre gli oggetti da PHP a Javascript (anche quelli diversi da String, Number etc.etc.) per 2 motivi

1) Potrei voler tradurre in javascript un oggetto PHP, poi modificarlo e poi riportarlo modificato a PHP.

2) Se porto in PHP un oggetto javascript di cui in PHP non ho la classe, comunque in PHP mi ritrovo un oggetto generico con delle proprietà valide.



X la questione delle prestazioni...

secondo me più si ottimizza, da ogni parte e meglio è.

Su questo credo che siamo tutti d'accordo

Poi c'è da tener presente che Javascript non è solo lato client, le classi javascript che abbiamo creato vanno benissmo anche se si programma in ASP/Javascript lato server...e lì l'ottimizzazione è importante.

In molti casi in cui c'è da interrogare Access o SQL Server con PHP, ho rinunciato all'interrogazione diretta PHP->Database Microsoft preferendo far interagire PHP e ASP attraverso la serializzazione.


Un'altra ipotesi carina sarebbe creare una classe analoga in C# per far interagire PHp e .NET.
In C# poi le prestazioni avrebbero un'importanza relativa visto che c'è la compilazione del codice.

[skidx]

Originariamente inviato da Fabio Heller
Tutti i tipi in Javascript sono oggetti..cosa facciamo?

Un'ipotesi potrebbe essere quella di far gestire al PHP in maniera opportuna la deserializzazione degli oggetti predefiniti JavaScript, che sono in numero finito.
Ad esempio, il deserializzatore lato server potrebbe riconoscere gli oggetti di tipo String, Date, Number, etc. e convertirli nel tipo di dato predefinito del PHP, mentre tutti gli altri oggetti non predefiniti in JS ma definiti dall'utente verrebbero gestiti alla solita maniera, cercando cioè la corrispondente classe PHP.

Non so se può piacerti una cosa del genere, io comunque l'ho detta.

[Fabio Heller]

Originariamente inviato da skidx

Un'ipotesi potrebbe essere quella di far gestire al PHP in maniera opportuna la deserializzazione degli oggetti predefiniti JavaScript, che sono in numero finito.
Ad esempio, il deserializzatore lato server potrebbe riconoscere gli oggetti di tipo String, Date, Number, etc. e convertirli nel tipo di dato predefinito del PHP, mentre tutti gli altri oggetti non predefiniti in JS ma definiti dall'utente verrebbero gestiti alla solita maniera, cercando cioè la corrispondente classe PHP.

Non so se può piacerti una cosa del genere, io comunque l'ho detta.

L'idea è buona, però vorrei inserire meno codice possibile sul lato PHP.

La soluzione migliore secondo me (sia che si decida si usare il prototype sia che si usi uno degli esmpi di Andrea)
è questa

1) Gli oggetti PHP, in Javascript diventano oggetti generici con in più una proprietà __class che contiene il nome della classe PHP originaria (in modo che poi si possano serializzare nuovamente in PHP).

2) I tipi base Javascript vengono trasformati nel quivalente PHP

Quindi

new String('ciccio') ;
diventa la stringa PHP 'ciccio'
new Number(5)
diventa l'intero 5...e così via

3) Gli oggetti Javascript che non hanno un corrispondente PHP diventano automaticamente oggetti "JsObject", ma con in più una proprietà che contiene il nome della classe Javascript originaria.
Così possono essere riportati in javascript alla loro classe originaria.
In quest'ultimo caso quindi seguirei il suggerimento di Skidx.

[andr3a]

Originariamente inviato da Fabio Heller
non ritengo fastidioso il prototype (visto che al momento è l'unico modo di programmare object oriented in Javascript)

io sta' frase non la capisco ... e come me tanti altri, perche' dici questo ?

ECMA è gia' un linguaggio ad oggetti, la proto serve ad implementare a tutti gli elementi di una determinata classe un metodo, non è l'unico modo per scrivere ad oggetti JS.

function pippo() {
this.test = 'oggetto';
}
var a = new pippo();
alert(a.test);

var pluto = new Object();
pluto.pippo = function() {
alert(this.s);
if(!this.s)
this. s = 'test';
}
alert(pluto.pippo()); // undefined
alert(pluto.pippo()); // test



cosa hanno di "non oggetto" queste variabili ?
Anche ActionScript 1.0 è identico ed è un linguaggio ad oggetti, gli oggetti non sono solo strict o chissa cosa, guarda python ... o forse non ho capito di cosa parli ... boh !

Originariamente inviato da Fabio Heller
il mio dubbio è un altro

come tradurre in PHP

var x = new String('bla bla') ;

oppure

var y = new Number(5) ;

?

lo so fabio, te l'ho detto, pensiamo ad una soluzione ... typeof per le string, undefined , number e boolean e' veramente utile, tutto il resto dovrebbe essere gestito dentro il metodo __object della mia classe ... è li che bisogna agire .... ma pensiamo ad un modo veloce che non incida troppo sui tempi di serializzazione, comunuqe estremamente piu' bassi di quelli di deserializzazione, quindi li si puo' perdere qualcosina