Pagina 35 di 37 primaprima ... 25 33 34 35 36 37 ultimoultimo
Visualizzazione dei risultati da 341 a 350 su 366
  1. #341
    Originariamente inviato da daniele_dll
    puoi serializzare e poi convertire prima di inviare i dati
    forse ti sfugge che il problema è la lenght errata che php mostra nella stringa serializzata ... devo convertire prima di serializzare ma penso sarebbe lostesso, che poi JS non veda i caratteri html mi semrbra strano ma non è comunque questa la soluzione (anche perchè i caratteri UTF-8 non devono essere ridotti di uno .... anche di 2 o 3, in certi casi ... ricontrollare ogni volta non sposta il carico sul client, ammazza il server come fa la JSON PEAR).

    ripongo la domanda:
    PHP_Serializer velocissima ma con potenziali problematiche in utf-8 oppure PHP_Serializer abbastanza veloce ma senza avere mai paranoie di conversione stringhe ?
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  2. #342
    e io ti ripeto la risposta:

    DOPO che serializzi, PRIMA che invii i dati al browser ... ti parsi TUTTA la stringa serializzata e una volta identificati i caratteri UTF8 scrivi l'entità ed aggiorni la length della stringa
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

  3. #343
    non ci siamo capiti ...

    1 - così facendo sovraccarico il server con un'operazione ulteriore che rende la PHP_Serializer non compatibile con una serializzata PHP, non in modo nativo

    2 - javascript vede benissimo le entità scritte dal php ...
    codice:
    <?php
    echo "
    <script>
    	var test = '".htmlentities('ÎÑTËRÑÅTÌÔñÁL', ENT_QUOTES, 'cp1251')."';
    	alert('len: ' + test.length + ' => value: ' + test);
    </script>
    ";
    ?>
    ... provare per credere, length 67 ...


    rimane la domanda di prima .... suvvia, non è difficile
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  4. #344
    Originariamente inviato da andr3a
    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
    sì infatti quando ho visto AJSHP mi è sembrata un cosa figosa, mo non ho ancora avuto occasione di provarla... magari rimedierò

    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
    sì scusa sono un pirla ho scritto al contrario la domanda posta come l'ho scritta prima non aveva senso, o meglio sembra che non sappia nemmeno cos'è AJAX
    intendevo il contrario, cioè: quand'è che è utile passare i dati in forma serializzata DA javascript A PHP?... io ogni volta che devo passare dei dati lo faccio con un form, o con una semplice richiesta GET...

  5. #345
    Originariamente inviato da Fredx
    io ogni volta che devo passare dei dati lo faccio con un form, o con una semplice richiesta GET...
    L'idea sarebbe quella di passare direttamente strutture complesse, cosa che con un form non puoi fare. Devi spezzettare la struttura in variabili e poi ricostruirla eventualmente lato server.

    Inviare una struttura serializzata dentro un'unica variabile può avere per questo dei vantaggi.

  6. #346
    Originariamente inviato da Fredx
    sì infatti quando ho visto AJSHP mi è sembrata un cosa figosa, mo non ho ancora avuto occasione di provarla... magari rimedierò
    aspetta qualche giorno, devo riscrivere AJSHP in modo da sfruttare la nuova classe PHP_Serializer ed essere compatibile anche con Safari o Konqueror, visto che l'unica che dava problemi era proprio la serializer.



    Originariamente inviato da skidx
    L'idea sarebbe quella di passare direttamente strutture complesse, cosa che con un form non puoi fare. Devi spezzettare la struttura in variabili e poi ricostruirla eventualmente lato server.
    Inviare una struttura serializzata dentro un'unica variabile può avere per questo dei vantaggi.
    soprattutto avrebbe poco senso creare una funzione / classe in grado solo di ricevere valori dal PHP senza poter reinviare tali valori (campo hidden di una form, ajax, altro).

    Comunque ho ufficializzato la versione 2.0 di PHP_Serailizer, il sorgente è su DEVPRO, le novità diverse.

    1 - ho riscritto da zero l'oggetto, ora per me molto più leggibile
    2 - l'oggetto serializza / deserializza le stringhe basandosi sul dato length in modo virtuale, ergo è sempre compatibile con un php che invia in UTF-8 , ISO o quello che è .... le prestazioni sono lievemente diminuite, si rimane sull' ordine di 1 secondo e mezzo per la conversione su una mole di dati elevata / complessa, tipo un array da 1.000 chiavi con array, classi o altro al suo interno per ogni chiave, l'insieme delle province e dei comuni, array semplici, si parsano in pochi decimi di secondo, per fare un esempio
    3 - la classe ora è compatibile con i seguenti browsers: Konqueror, Safari, KDE based, FireFox 1, FireFox 1.5, IE 6, IE 7 beta 2 (probabilmente anche con IE 5 e 5.5 .... non ho ancora testato), Opera 8, 8.5, probabilmente Opera 9 ... le prestazioni sono analoghe in tutti browsers sebbene alcuni richiedano prototypes dedicate, diverse o più complesse.



    A chi ancora dovesse domandarsi "ma a cosa serve" ? ... auguro la buona notte
    A chi stesse aspettando una versione più affidabile/compatibile .... beh, questa penso che rimarrà uguale per molto tempo, poichè non ho altre ottimizzazioni da fare ne browsers da controllare, lavora sul 98% degli usati, spero sia sufficiente
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  7. #347
    confermo IE5 ed IE 5.5

    qui la pagina per testare anche il vostro browser
    http://devpro.phpsoft.it/php_serializer/
    [ visto che "di la" nessuno ha alzato un dito ... ]
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  8. #348
    Originariamente inviato da andr3a
    confermo IE5 ed IE 5.5
    sai che le versioni standalone utilizzano js del 6 vero?

  9. #349
    Originariamente inviato da andrea.paiola
    sai che le versioni standalone utilizzano js del 6 vero?
    dici sul serio ? ... a me sembra di no, tant'è che ho dovuto modificare la pagina perchè la EverGreen sul 6 e 5.5 andava, su 5 no ... idem per il push dell' array, sul 5 non va (giustamente), quindi o il 5 stand alone è una cosa a parte, oppure ti chiederei gentilmente di confermare che 5 e 5.5 sono comunque compatibili (o anche altri browser), grazie
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  10. #350
    Originariamente inviato da andr3a
    dici sul serio ?
    per quanto ne so sì... IE5 e IE5.5 usano il motore js del IE installato (quindi 6 o 7 beta per il momento)... non ho IE5 o IE5.5 non standalone e se non ho capito male hai già detto che funzia :master:

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2026 vBulletin Solutions, Inc. All rights reserved.