Interazione PHP e Javascript

[Fabio Heller]

Originariamente inviato da andr3a
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.

Ecma è un linguaggio a oggetti abbastanza completo solo grazie al prototype che è l'unico modo di creare vere classi, applicare l'ereditarietà, aggiungere anche metodi statici.

pluto.pippo = function() {
alert(this.s);
if(!this.s)
this. s = 'test';
}

aggiungere metodi in questo modo è possibile, ma non è il sistema consigliato, nè il più leggibile.
Inoltre se utilizzi Javascript lato server è un sistema che sarebbe preferibile evitare in quanto più dispendioso per l'interprete rispetto all'utilizzo del prototype.

La nuova edizione di Ecma non è ancora ufficiale ed è stata adottata in anteprima da javascript .NET e Actionscript 2.0.
Hanno eliminato il prototype solo per adeguare Javascript agli altri linguaggi Object Oriented e non perchè il prototype fosse un male anzi....
Purtroppo senza il prototype si è persa la possibilità di estendere i tipi nativi.

Nessun appassionato di Javascript, nè alcun manuale ti dirà che il prototype è qualcosa di negativo.
Sarebbe come dire che usare "extends" in un linguaggio OO classico è male.
Il prototype può essere forse un "fastidio" nella mia classe per la serializzazione perchè aggiunge un metodo a tutti i tipi primitivi, ma non interferisce perchè tutti i metodi sono esclusi dalla serializzazione.

[andr3a]

Originariamente inviato da Fabio Heller
Ecma è un linguaggio a oggetti abbastanza completo solo grazie al prototype che è l'unico modo di creare vere classi, applicare l'ereditarietà, aggiungere anche metodi statici.

è proprio questo che non mi torna ... non puoi avere private con prototype, o sbaglio ?
prototype e' sovrascrivibile tanto quanto qualunque altro metodo riferito con this e non permette di avere metodi privati, o sbaglio ?

Non sto' dicendo che prototype e' il male, sto' dicendo che secondo me e' una cosa in piu' e non l'unico modo, per altro limitato e rdondante rispetto ad altri ( riscrivere ogni volta la classe.prototype, 2 bolas ), di scrivere oggetti in JavaScript.

Originariamente inviato da Fabio Heller
aggiungere metodi in questo modo è possibile, ma non è il sistema consigliato, nè il più leggibile.

e perche' mai ?
this si usa in AS2.0 come in Python e PHP .. cos'ha' di cosi' strano un oggetto con metodi pubblici, this.method e variabili pubbliche, this.var piuttosto che una serie "infinita" di
Classe.prototype.method ... eccetera ?

Originariamente inviato da Fabio Heller
Inoltre se utilizzi Javascript lato server è un sistema che sarebbe preferibile evitare in quanto più dispendioso per l'interprete rispetto all'utilizzo del prototype.

se lo utilizzo lato server si presumi si bytecompili o byteencodi ... e se il risultato e' un oggetto piu' dispendioso non darei la colpa al javacript ... pero' ammetto di non conoscere js.net

Originariamente inviato da Fabio Heller
La nuova edizione di Ecma non è ancora ufficiale ed è stata adottata in anteprima da javascript .NET e Actionscript 2.0.
Hanno eliminato il prototype solo per adeguare Javascript agli altri linguaggi Object Oriented e non perchè il prototype fosse un male anzi....

AS2.0 e' un meticcio tra l' uno e il 3 ... non lo considererei piu' di tanto, seppur piu' vicino a Java che al vero nuovo ECMA , non so com'e' per .NET

Originariamente inviato da Fabio Heller
Purtroppo senza il prototype si è persa la possibilità di estendere i tipi nativi.

sicuro ?
class MyString extends String ?

Originariamente inviato da Fabio Heller
Nessun appassionato di Javascript, nè alcun manuale ti dirà che il prototype è qualcosa di negativo.

errore ... eccotene uno che non lo apprezza chissa' quanto, non lo usa e non ne sente alcuna mancanza

Originariamente inviato da Fabio Heller
Sarebbe come dire che usare "extends" in un linguaggio OO classico è male.

non e' male, si usa quando serve .. che e' diverso da: e' l'unico modo ... e' come se dicessi che in PHP se non usi extends non e' un oggetto ... e' cosi' ? no, c'e' la classe e c'e' quella estesa, quando serve, non "sempre e solo".

Originariamente inviato da Fabio Heller
Il prototype può essere forse un "fastidio" nella mia classe per la serializzazione perchè aggiunge un metodo a tutti i tipi primitivi, ma non interferisce perchè tutti i metodi sono esclusi dalla serializzazione.

non interferisce solo NELLA SERIALIZZAZIONE, ma interferisce con tutto il resto del sistema, tu dici a me di mettere un vincolo "non usate new String" ... ma non credi che allora tu dovresti dire di "non usate altre oggetti all' infuori di queste 2 funzioni" ???

se io mi aspetto qualcosa in un
for(var a in myobj)

perche' tu ti intrometti ?


e' per questo che ho rifatto il tutto, non perche' non funzionasse o fosse cosi' schifoso usare prototype, semplicemente perche' io non uso 2 soli files JS per fare una sola cosa ( serializzare ) , ne uso mediamente 2 o 3 (o piu' ) incrociati e non voglio trovarmi per nessun motivo, sorprese o oggetti "miei" modificati , ecco perche' odio prototype in questo caso



ma non stiamo arrivando a niente, oltre il flame, come possiamo risolvere la questione ?

cosa facciamo passare per constructor e cosa no ?

[andr3a]

buon giorno forum

ho dato ascolto ai consigli di Fabio ed ho implementato la conversione dei seguenti tipi JS:

new String
new Number
new Boolean

assieme, ovviamente a
new Object('string')
new Object(1)
new Object(true)

ho anche fatto un fixed per una svista sul typeof 'function' che dava un errore in serializzazione.

Fabio, gradirei una tua opinione sull' aggiunta che comporta un solo if dentro il solo metodo __object di serialize e l'aggiunta di un oggetto privato in grado di reindirizzare i costruttori riconosciuti.

Ditemi se da problemi o se manca qualcosa, grazie mille
http://www.devpro.it/code/102.html



[edit]
m'e' venuto anche un dubbio ... le funzioni in as vengono convertite in [type Function] ... pensate sia il caso di non perdere l'informazione e serializzare le funzioni come stringa s:15:"[type Function]"; oppure è solo un'aggiunta inutile che puo' fare confusione ?

Fabio tu ad esempio usavi [type Object] se non erro, cosa ne pensate ?

[Fabio Heller]

ma non stiamo arrivando a niente, oltre il flame, come possiamo risolvere la questione ?

A me non sembra un flame, ma una sana discussione su javascript (e PHP, altrimenti i moderatori ci azzannano).

Originariamente inviato da andr3a
è proprio questo che non mi torna ... non puoi avere private con prototype, o sbaglio ?
prototype e' sovrascrivibile tanto quanto qualunque altro metodo riferito con this e non permette di avere metodi privati, o sbaglio ?

la visibilità dei membri non è parte di javascript, puoi raggiungerlasolo con workaround vari.
Il prototype è parte di Javascript ed al momento è l'unico modo per estendere le "classi" (sia predefinite che create dall'utente).
Ho messo classi tra virgolette perchè Js è un linguaggio Object Oriented basato sulle funzioni e non sulle classi.

Non sto' dicendo che prototype e' il male, sto' dicendo che secondo me e' una cosa in piu' e non l'unico modo, per altro limitato e rdondante rispetto ad altri ( riscrivere ogni volta la classe.prototype, 2 bolas ), di scrivere oggetti in JavaScript.

Ma al momento è l'unico modo di riprodurre certe funzionalità OO in Javascript

this si usa in AS2.0 come in Python e PHP .. cos'ha' di cosi' strano un oggetto con metodi pubblici, this.method e variabili pubbliche, this.var piuttosto che una serie "infinita" di
Classe.prototype.method ... eccetera ?

Ti faccio un esempio con il tuo codice

this.__string = function(__s) {
			return ('s:'+__s.length+':"'+__s+'";');
		}
		this.__number = function(__s) {
			return ((String(__s).indexOf('.')==-1)?'i:'+__s+';':'d:'+__s+';');
		}
		this.__boolean = function(__s) {
			return ('b:'+(__s?'1':'0')+';');
		}
		this.__undefined = function(__s) {
			return ('N;');		
		}
		this.__object = function(__s) {
			var n;
			var a = 0;
			var ser = '';
			for(var b in __s) {
				n = (__s[b] == null);
				if(n || (__s[b].constructor != Function && b != '__class')) {
					ser+=(!isNaN(b))?this.__number(b):this.__string(b);
					ser+=n?this.__undefined(n):this['__'+typeof(__s[b])](__s[b]);
					a++;
				}
			}
			return ('a:'+a+':{'+ser+'}');
		}
		if(what == null)
			var ser = this.__undefined(what);
		else
			var ser = this['__'+typeof(what)](what);
		return ser;

Ogni volta che viene chiamato questo
this['__'+typeof(what)](what);

la definizione e l'assegnazione della funzione devono essere ri-valutate

this.proprieta = function() etc.etc.

Questo, se è accettabile lato client, lato server non è il massimo.
Con il prototype non si verifica.

se lo utilizzo lato server si presumi si bytecompili o byteencodi ... e se il risultato e' un oggetto piu' dispendioso non darei la colpa al javacript ... pero' ammetto di non conoscere js.net

Il Js.net è quasi identico a Actionscript 2.0 e prevede le classi, mi riferisco al Javascript di ASP 3.0.
Il prototype è parte di javascript a tutti gli effetti e serve ad estendere le classi, creare metodi statici ereditabili etc.etc. Quindi quando si può usare non c'è nulla di male.

sicuro ?
class MyString extends String ?

Questo è quanto ti permettono di fare AS 2.0 e JS.NET
Così crei una classe figlia ma non puoi estendere le proprietà della classe madre. Male o bene che sia, solo il prototype ti consente di farlo.

errore ... eccotene uno che non lo apprezza chissa' quanto, non lo usa e non ne sente alcuna mancanza

Però sei inevitabilmente costretto a rinunciare a certe cose, come l'ereditarietà tra "classi" javascript.

non e' male, si usa quando serve .. che e' diverso da: e' l'unico modo ... e' come se dicessi che in PHP se non usi extends non e' un oggetto ... e' cosi' ? no, c'e' la classe e c'e' quella estesa, quando serve, non "sempre e solo".

Non ho detto che è l'unico modo, ho detto che è un modo lecito di fare le cose. E non credo dia fastidio nel caso della serializzazione.
A te originariamente creava problemi perchè non filtravi i metodi.

non interferisce solo NELLA SERIALIZZAZIONE, ma interferisce con tutto il resto del sistema, tu dici a me di mettere un vincolo "non usate new String" ... ma non credi che allora tu dovresti dire di "non usate altre oggetti all' infuori di queste 2 funzioni" ???
se io mi aspetto qualcosa in un
for(var a in myobj)

perche' tu ti intrometti ?

Non è che toglie o sovrascrive qualcosa, lo aggiunge

se fai
for(var a in myobj)

in myobj ci sono molte altre cose di cui non farai nulla, tutti i metodi ad esempio (che devono essere ignorati). Io ne ho aggiunto uno in più che non chiede nulla se non essere ignorato come qualsiasi altro metodo.

e' per questo che ho rifatto il tutto, non perche' non funzionasse o fosse cosi' schifoso usare prototype, semplicemente perche' io non uso 2 soli files JS per fare una sola cosa ( serializzare ) , ne uso mediamente 2 o 3 (o piu' ) incrociati e non voglio trovarmi per nessun motivo, sorprese o oggetti "miei" modificati , ecco perche' odio prototype in questo caso

Come detto poco più su, viene aggiunto un metodo agli altri che sono inevitabilmente presenti e che devono essere tutti filtrati.
Ad ogni modo non sto difendendo la scelta del prototype a tutti i costi, facciamo bene a prendere in considerazione altre soluzioni e hai fatto bene a riscrivere tutto perchè sicuramente il risultato finale sarà migliore e più ponderato di quello ottenuto da me in un pomeriggio. Abbiamo già scoperto e risolto alcuni bachi.
Semplicemente sto difendendo il provero prototype come costrutto che è parte integrante e utile di Javascript.

In ogni caso sono d'accordo su una cosa: qualora Javascript dovesse cambiare in stile AS 2.0 e Js.NET, l'unico modo sicuro al 100% di rendere la libreria retrocompatibile sarebbe rinunciare al prototype e usare soltanto le funzioni.

Comunque ok, molliamo le divagazioni...

cosa facciamo passare per constructor e cosa no ?

Io vedo due soluzioni possibili (do il prototype per bocciato)

La prima
--------------
function j2p_getType(tipo)
{
var myType = '' ;
switch(tipo.constructor)
{
case Boolean:
myType = 'boolean' ;
break ;

case Number:
myType = 'number' ;
break ;

case String:
myType = 'string' ;
break ;

case Array:
myType = 'array' ;
break ;

case Object:
myType = 'object' ;
break ;

default:
var func = 'function' ;
tipo = String(tipo)
myType = tipo.substring(tipo.indexOf(func) + func.length, tipo.indexOf('(') ) ;
break ;
}

return myType ;
}


la seconda
---------------

function j2p_extract2(tipo)
{
var func = 'function' ;
tipo = String(tipo)
myType = tipo.substring(tipo.indexOf(func) + func.length, tipo.indexOf('(') ) ;
return(myType.toLowerCase()) ;
}

quale sia la più conveniente (performante) non lo so

[andr3a]

Originariamente inviato da Fabio Heller
Ogni volta che viene chiamato questo
this['__'+typeof(what)](what);

la definizione e l'assegnazione della funzione devono essere ri-valutate

Con il prototype non si verifica.

consigli di fare una proto interna all' oggetto PHP_Serializer ?

Originariamente inviato da Fabio Heller
Non ho detto che è l'unico modo, ho detto che è un modo lecito di fare le cose.

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

comunque, hai visto la soluzione da me adottata per la questione new String etc etc ?
come ti sembra ?

pensavo, a questo punto, di adottare la proto per un oggetto interno, cosi' da non rivalutare niente, un
__object[typeof(something)]() per intenderci, che ne dici ?

[Fabio Heller]

Originariamente inviato da andr3a

consigli di fare una proto interna all' oggetto PHP_Serializer ?

Non so se possa funzionare, ma tentare non nuoce

Non c'è contraddizione nelle mie frasi: il prototype è l'unico modo di programmare a oggetti in javascript con tutte le funzionalità tipiche dei linguaggi OO, ma non è l'unico modo per realizzare la serializzazione.

comunque, hai visto la soluzione da me adottata per la questione new String etc etc ?
come ti sembra ?

No quale soluzione?

pensavo, a questo punto, di adottare la proto per un oggetto interno, cosi' da non rivalutare niente, un
__object[typeof(something)]() per intenderci, che ne dici ?

Potrebbe andare ma non ho mai provato internamente ad una funzione....
Un'altra cosa typeof() con le parentesi non ti dà un exception in certi casi?
Se non sbaglio la sintassi standard è quella senza parentesi

typeof variabile

[andr3a]

Originariamente inviato da Fabio Heller
il prototype è l'unico modo di programmare a oggetti in javascript con tutte le funzionalità tipiche dei linguaggi OO, ma non è l'unico modo per realizzare la serializzazione.

ricominciamo ?

Originariamente inviato da Fabio Heller
No quale soluzione?

var __ctypes = new Object();
__ctypes[Boolean] = function(what) {
	return serialize(Boolean(what));
}
__ctypes[Number] = function(what) {
	return serialize(Number(what));
}
__ctypes[String] = function(what) {
	return serialize(String(what));
}
// .. dentro __object
if(__ctypes[__s.constructor])
	n = __ctypes[__s.constructor](__s);
else
// ... serializzazione

Originariamente inviato da Fabio Heller
Un'altra cosa typeof() con le parentesi non ti dà un exception in certi casi?

mai

Originariamente inviato da Fabio Heller
Se non sbaglio la sintassi standard è quella senza parentesi
typeof variabile

può darsi ... comq mai un exception ... :master:



[edit]
riguardo il discorso di far tornare la funzione come stringa '[type Function]' invece che mi dici ? :master:

[andr3a]

[ mega edit ]
ok ... avevo scritto un papiro di roba, poi ho scoperto che IE è talmente fico che non capisce quando new Date è il caso di prenderlo o meno ... chi avesse fatto il test, bastava cambiare l'ordine per accorgersi che IE non è affidabile con le variabili di tipo data durante un esecuzione ... evviva IE, ancora debug per me

[Fabio Heller]

Originariamente inviato da andr3a

var __ctypes = new Object();
__ctypes[Boolean] = function(what) {
	return serialize(Boolean(what));
}
__ctypes[Number] = function(what) {
	return serialize(Number(what));
}
__ctypes[String] = function(what) {
	return serialize(String(what));
}
// .. dentro __object
if(__ctypes[__s.constructor])
	n = __ctypes[__s.constructor](__s);
else
// ... serializzazione

Ah ok, è un po' strano che quelle chiavi siano accettate in quel modo ma se funziona con tutti i browser va benone.

riguardo il discorso di far tornare la funzione come stringa '[type Function]' invece che mi dici ? :master:

Non ho capito

[andr3a]

Originariamente inviato da Fabio Heller
Non ho capito

in ActionScript (ECMA)

function f() { trace('f'); }
trace(f); // [type Function]

idem se passi per loadvars o altro, in pratica viene passato il "toString" forzato ad un generico [type Function] ... in php risulterebbe stringa, in js sarebbe inutile ma potrebbe dire che era una funzione

cmq mi sa che non lo metto, frega niente


Segnalazione bachetto per Fabio e la sua serialize
è vero che hai corretto l' array vuoto, ma è anche vero che se serializzi una variabile tipo:
var a = new Array();
la tua classe mostra un Oggetto chiamato Array con zero chiavi, mentre se serializzi
var o = new Object();
la tua classe mostra un Array a zero chiavi ... forse c'e' qualcosa che non va ?
Personalmente, visto che gli Array, almeno quelli, sono intesi identici in php come in js, io ho optato per serializzare come Array qualunque array JS, a prescindere dal tipo di chiavi, mentre tutti gli altri Oggetti verranno serializzati come oggetti.
new Object non esiste in php, ergo verra' inviato come oggetto.
Vantaggi ? pochi, se non per il fatto che in avascript se invii un oggetto torna un oggetto, se invii un array torna un array, adesso il tipo di dato è rispettato in invio e ritorno.


Aggiornamenti dell' ultima ora (alba)
peggio di PHP 5.1 ... ho sfornato quella che dovrebbe essere, salvo bug reports, la versione definitiva e completamente riscritta della classe PHP_Serialize !
Nuove features: serializza e deserializza anche gli oggetti, e' basata su prototype sulla classe stessa quindi non cambia in alcun modo alcun oggetto o variabile di tutto il javascript che volete o utilizzate !

Un'ora di tests
Dopo aver fatto non so quanti tests per affidabilità posso dire che i casi generici (non si sa mai) non hanno mai dato nemmeno mezzo problema.

Prestazioni a confronto
Questo e' il risultato di 5 click per ogni pagina dedicata su ogni browser, i dati sono l media di questi 5 click per ser (serializzazione) e uns (deserializzazione) di un array da 2000 chiavi numeriche contenente booleani (vedi poi).

andr3a
_____________________________
browser		ser	uns
-----------------------------
FireFox		158	108
Opera		96	98.4
IE 6 SP2	486.8	398.8
-----------------------------
		247	202

Migliore prestazione generica: deserializzazione



Fabio
_____________________________
browser		ser	uns
-----------------------------
FireFox		164.2	174
Opera		224.4	68
IE 6 SP2	384.8	456.2
-----------------------------
		258	233

Migliore prestazione generica: serializzazione su IE 6 SP2

Considerazioni
Tutti gli altri test che ho fatto erano sbagliati, tempisticamente parlando, poichè essendo le classi di Fabio "prepotenti", se testavo le 2 versioni sulla stessa pagina la mia faticava di più perche' ogni oggetto aveva almeno un metodo in più, con la deserializzazione 2 ... ergo per ogni variabile mi faceva 2 cicli in più, altro motivo per non usare, secondo me, la proto su tipi di dato generici, troppo fastidiosa.
Per concludere, questi risultati sono stati fatti con le seguenti pagine:

Pagina bench andr3a
<script type="text/javascript" src="PHP_Serializer.js"></script>
<script type="text/javascript">
var a = new Array();
for(var c = 0; c < 2000; c++) {
a[c] = new Boolean(false);
}
var time;
var start;
var php;
var result;
var rem;
php = new PHP_Serializer();
time = new Date();
start = time.getTime();
result = php.serialize(a);
time = new Date();
document.write('Serializer andr3a [' + result.length + '] : ' + (time.getTime() - start) + '
' + result + '

');
rem = result;
time = new Date();
start = time.getTime();
result = php.unserialize(result);
time = new Date();
start = (time.getTime() - start);
document.write('UnSerializer andr3a : ' + start + '
Se riserializzato è identico ? ' + (rem === php.serialize(result)) + '<hr />');
</script>



Pagina bench Fabio
<script type="text/javascript" src="PHPserializer.js"></script>
<script type="text/javascript" src="PHPunserializer.js"></script>
<script type="text/javascript">
var a = new Array();
for(var c = 0; c < 2000; c++) {
a[c] = new Boolean(false);
}
var time;
var start;
var php;
var result;
var rem;
php = new PHPserializer();
time = new Date();
start = time.getTime();
result = php.render(a);
time = new Date();
document.write('Serializer Fabio [' + result.length + '] : ' + (time.getTime() - start) + '
' + result + '

');
rem = result;
php = new PHPunserializer();
time = new Date();
start = time.getTime();
result = php.parse(result);
time = new Date();
start = (time.getTime() - start);
php = new PHPserializer();
document.write('UnSerializer Fabio : ' + start + '
Se riserializzato è identico ? ' + (rem === php.render(result)) + '<hr />');
</script>


Si ma dov'e' la mia nuova classe ?
qui http://www.devpro.it/code/102.html


Vuoi pareri / debug / consigli ?
Ovviamente, grazie