TRANSFERT DE DONNÉES FLASH <-> PHP - PETITE SUBTILITÉ AVEC JSON (AS3 - PHP5)
fedebul
Messages postés129Date d'inscriptionvendredi 17 mars 2006StatutMembreDernière intervention27 février 2012
-
27 févr. 2012 à 20:14
aerolyte
Messages postés465Date d'inscriptionmardi 17 avril 2007StatutMembreDernière intervention 4 mai 2013
-
19 avril 2013 à 14:38
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
aerolyte
Messages postés465Date d'inscriptionmardi 17 avril 2007StatutMembreDernière intervention 4 mai 20131 19 avril 2013 à 14:38
Effectivement si ton objectif est de stocker sur un serveur des variables, je m'incline.
Toutefois, je permet de rappeler que cela à un cout:
1/ nécessité de faire des requetes qui demande un tesmps d'accés imcompressible.
2/ surcharge non négligable de l'activité du sserveur (traitement +enregistrement)
3/ gestion des erreurs
Si ton objectif est juste de stocker des variables, une solutioon pertinente est le DOM Storage.
Car tes variables sont stocker dans la navigateur, le volume disponible est relativement important, l'accessibilité simplifiée, et le code php est pas plus long que celui donné dans ta source.
Alors c'est pas la solution miracle, car comme je l'ai précédemment écrit, seul les navigateur récent , permettent de faire du DOMstorage.
Je ne répond pas a ton messag eprécédent pour etre pénible, mais plutôt pour informer les possible visiteur, des alternatives exitantes.
Cordialement.
P.S:c'est bien malheureux que l'as3 n'ai plus aucun avenir, car c'est pour encore quelques années encore le language compilé le plus performant.
Loubiou
Messages postés150Date d'inscriptionmercredi 26 juin 2002StatutMembreDernière intervention 5 décembre 2008 19 avril 2013 à 11:40
Bonjour,
Je vais essayer de faire une réponse groupée à Top30 et à AEROLYTE car en relisant ma source, je constate que je n’ai pas été clair du tout et je m’en excuse.
LA PROBLÉMATIQUE :
Stocker le contenu d’un shareObject sur un espace disque disant en vue de le réutiliser dans flash en évitant des opérations d’assignation de variables (car il y en a beaucoup !) Ce qui fait que l’envoi d’un fichier texte comme propose Top30 est exclu car cette solution est très exactement ce que je veux éviter (d’assigner chaque variables à une valeur à l’envoi et au retour).
Sinon, ma source n’a aucune utilité !!
Ma solution réside en 2 choses :
Une opération de mise en forme simple JSON (sérialisation sans passer en revue toutes les variables) et une opération de stockage de l’objet sérialisé brut sur le serveur web grâce à une fonction PHP.
Du coup, il suffit de le charger comme un fichier de faire l’opération de désérialisation de base pour pouvoir l’exploiter comme shareObject.
Concernant la norme WC3, il n’en est pas question non plus puisque le html n’est pas sollicité dans la mesure où l’on reste dans une application flash (php servant d’interface).
Pour conclure, la norme et les bonnes pratiques ne sont pas toujours les bons chemins à suivre pour obtenir la productivité par la performance ;-)
J’espère avoir été plus clair dans mon explication. Mon tors a été de penser que le code était assez explicite sur cette source qui est toujours d'actualité que ce soit pour flash ou pour AIR.
aerolyte
Messages postés465Date d'inscriptionmardi 17 avril 2007StatutMembreDernière intervention 4 mai 20131 18 avril 2013 à 22:48
je déterre cette source pour confirmer que la bonne solution a ton hypothèse est bien de passer par le DOMStorage. bien qu'il ne soit implanté que pour les navigateur les plus récents.
tu stringify ton json, tu stockes.
tu rapelles et tu parses.
C'est léger, rapide et surtout c'est a l'épreuve des balles^^.
Cordialement
top30
Messages postés1158Date d'inscriptionvendredi 21 février 2003StatutMembreDernière intervention 6 août 2010 23 mars 2012 à 10:40
La bonne ligne est :
request.data= new URLVariables( "name="+name+"&data"+data.toString() ) ;
top30
Messages postés1158Date d'inscriptionvendredi 21 février 2003StatutMembreDernière intervention 6 août 2010 23 mars 2012 à 10:38
Si ton but est la simplicté tu peux améliorer tout ca !
Ne passes pas par la sérialisation Json...
Gardes directement les variables au format URL dans un fichier texte.
Un truc du genre:
// Ecriture des données de Flash vers PHP ////////////////////////////
var data : URLVariables= new URLVariables();
data.prenom = "Bill";
data.nom = "Boquet";
var name :String= "[URL]/monFichier.txt"
var request :URLRequest= new URLRequest("[URL]/writeData.php");
request.method = URLRequestMethod.POST;
request.data= new URLVariables( "name="+name+"&"+data.toString() ) ;
var loader :URLLoader = new URLLoader();
loader.addEventListener( Event.COMPLETE, onDataWrite );
loader.load(request);
function onDataWrite( $e:Event ):void{
trace("Données enregistrées");
}
// Récupération des données de PHP vers Flash /////////////////////////
var loader :URLLoader = new URLLoader();
loader.load( new URLRequest(name));
loader.addEventListener(Event.COMPLETE, onDataRead );
public function onDataRead( $e:Event ){
var data :URLVariables= new URLVariables($e.target.data) ;
for (var name :String in data ) trace( name, data[name] );
}
// Le PHP "writeData.php", toujours aussi simple...
<?php
C'est ecrit à á volée, plus pour le principe que pour le bon fonctionnement. A vérifier !
Loubiou
Messages postés150Date d'inscriptionmercredi 26 juin 2002StatutMembreDernière intervention 5 décembre 2008 23 mars 2012 à 09:49
Bonjour tout le monde.
Je ne suis pas persuadé que je me sois bien exprimé pour expliquer cette source.
Je réponds à Aerolyte, concernant le W3C. Effectivement c’est recommandé mais j’écris ce fichier en PHP via une liaison flash pour avoir une rétention de l’information et éviter une série de codage-décodage de la function JSON. Le fichier n’est pas énorme et évite des lignes d’instructions dans PHP.
Ainsi depuis mon appli AIR, je récupère directement mes données directement au format JSON comme si elles venaient d’être envoyées après par exemple plusieurs jours. J’évite ainsi des instructions pour l’écriture éventuelle d’un xml, d’un fichier binaire et un nouveau codage pour envoyer à flash et un nouveau décodage du côté réception flash.
J’utilise les shareObjects car le client est une sur une appli AIR et certaines informations demandent un cryptage et une rétention locale qui ne nécessite pas d’implémenter une base de données locale. Il se trouve donc que j’ai utilisé mon bout de code, issu directement de mon appli. Bien entendu, il n’est pas forcément utile d’utiliser un shareObject. Ici c’est juste parce que ça se présentait comme ça.
top30
Messages postés1158Date d'inscriptionvendredi 21 février 2003StatutMembreDernière intervention 6 août 2010 21 mars 2012 à 23:09
Pourquoi utilises-tu un SharedObject vu que tu gardes tout via PHP ?
Pourquoi gardes-tu le SharedObject dans un tableau vu que tu n'énumères que que le premier élément de ce tablau ?
Moi j'ai juste l'impression que c'est plein de bon sentiments, mais la réalisation et l'utitilisation laisse à désirer....
Tu pourrais trés bien créer une classe, passer le nom du futur fichier à PHP, etc. etc...
Ca laisse à désirer, je mettrais seulement 6. C'est bien mieux que la moyenne des dernères sources mais c'est pas génial quand même.
Bonnce change et voir si tu améliores tout ca...
aerolyte
Messages postés465Date d'inscriptionmardi 17 avril 2007StatutMembreDernière intervention 4 mai 20131 13 mars 2012 à 09:57
bonjour Loubiou, peg'
Concernant cette source je me demande si du coup il serait pas préférable d'utiliser le DOM storage pour les navigateur rècent. Ce qui est d'ailleurs conseiller par le W3C
Sinon je profite en peu de la visibilité de ta source pour faire appele a des compétences.
J'ai mis au point un nouveau modèle d'utilisation des bases de données hièrachique.
mais il me manque un peu d'aide d'expert en requète sql
aerolyte
Messages postés465Date d'inscriptionmardi 17 avril 2007StatutMembreDernière intervention 4 mai 20131 12 mars 2012 à 23:57
Du coup je me demande si c'est pas plus cohérent de passer par du DOM STORAGE, qui est d'ailleur recommandé par le W3C
Cordialement
pegase31
Messages postés6138Date d'inscriptiondimanche 21 décembre 2003StatutModérateurDernière intervention 4 septembre 201312 29 févr. 2012 à 22:19
pour le poids, tu gagnerais 75% environ (tests persos) et pour le format, il n'y a aucun "parseur" à faire, donc pas de classe à ajouter en plus : gain de poids dans le flash et dans la donnée. Mais je comprend que ce format rebute par son style "non-humain" dans l'écriture ;)
Peg'
Loubiou
Messages postés150Date d'inscriptionmercredi 26 juin 2002StatutMembreDernière intervention 5 décembre 2008 29 févr. 2012 à 21:00
Ben je ne suis pas certain que le fichier final en binaire soit moins lourd et question décodage dans flash, le binaire n'est pas du tout aussi simple que la class JSON avec sa ligne unique d'instruction. Bref la solution proposée est performante, fiable et nous convient parfaitement.
pegase31
Messages postés6138Date d'inscriptiondimanche 21 décembre 2003StatutModérateurDernière intervention 4 septembre 201312 29 févr. 2012 à 12:26
Alors le plus efficace aurait été d'encoder en binaire, alors, sachant que ce format est lisible des deux côtés en natif, sans parler du fait que côté poids et sécurité, c'est encore plus performant.
Peg'
Loubiou
Messages postés150Date d'inscriptionmercredi 26 juin 2002StatutMembreDernière intervention 5 décembre 2008 29 févr. 2012 à 05:00
Hello Peg,
effectivement j'utilise une classe déjà et sur la quantité de données je gagne plus de temps machine à sérialiser les données en JSON et d'envoyer à PHP qui va écrire en dur le contenu pour un prochain décodage en AS3, que de coder et décoder en XML. Effectivement pour peut de données ça n'a pas d'interret.
Pour tout te dire, j'ai eu besoin de cette fonction pour récupérer des données envoyée par flash à l'occasion d'un paiement en ligne. Comme le système de paiement est en https et géré par la banque, j'étais limité en taille de données à passer dans leurs variables. Avec cette méthode, je récupère les données à l'issue du paiement sans pertes et sans limite (256 niveaux maintenant) Sauf que pour ce cas de figure j'encode et écris les données depuis PHP (ce qui est un peut la meme chose).
Conclusion, gain de temps énorme, peut de ligne de codes et fiabilité puisque le fichier en dur est strictement conforme à la sérialisation JSON sans parler de la sécurité des données confidentielles !
Voilà, tu sais tout :-)
pegase31
Messages postés6138Date d'inscriptiondimanche 21 décembre 2003StatutModérateurDernière intervention 4 septembre 201312 28 févr. 2012 à 19:53
Bonsoir, en fait tu ne fais qu'utiliser une classe JSON déjà existante.
Pourquoi ne pas envoyer directement tes données en XML ?
Peg'
Loubiou
Messages postés150Date d'inscriptionmercredi 26 juin 2002StatutMembreDernière intervention 5 décembre 2008 27 févr. 2012 à 21:20
Non malheureusement je n'ai pas d'appli toute faite. J'ai écrit ce bout de code pour ceux qui ont besoin d'un transfert de données vers un serveur web en utilisant la sérialisation JSON. Cette source s'adresse aux utilisateurs JSON comme alternative au codage décodage coté PHP puisque nous enregistrons les données reçues en fichier tel que, il est pret à être récupérer par une autre appli flash ou la même à un temps différé.
J'utilise cette façon de faire pour stocker une quantité de données en backup en dur.
fedebul
Messages postés129Date d'inscriptionvendredi 17 mars 2006StatutMembreDernière intervention27 février 2012 27 févr. 2012 à 20:14
bonjour et merci pour cette source ! y'a t'il un exemple d'utilisation ?
Merci beaucoup
19 avril 2013 à 14:38
Toutefois, je permet de rappeler que cela à un cout:
1/ nécessité de faire des requetes qui demande un tesmps d'accés imcompressible.
2/ surcharge non négligable de l'activité du sserveur (traitement +enregistrement)
3/ gestion des erreurs
Si ton objectif est juste de stocker des variables, une solutioon pertinente est le DOM Storage.
Car tes variables sont stocker dans la navigateur, le volume disponible est relativement important, l'accessibilité simplifiée, et le code php est pas plus long que celui donné dans ta source.
Alors c'est pas la solution miracle, car comme je l'ai précédemment écrit, seul les navigateur récent , permettent de faire du DOMstorage.
Je ne répond pas a ton messag eprécédent pour etre pénible, mais plutôt pour informer les possible visiteur, des alternatives exitantes.
Cordialement.
P.S:c'est bien malheureux que l'as3 n'ai plus aucun avenir, car c'est pour encore quelques années encore le language compilé le plus performant.
19 avril 2013 à 11:40
Je vais essayer de faire une réponse groupée à Top30 et à AEROLYTE car en relisant ma source, je constate que je n’ai pas été clair du tout et je m’en excuse.
LA PROBLÉMATIQUE :
Stocker le contenu d’un shareObject sur un espace disque disant en vue de le réutiliser dans flash en évitant des opérations d’assignation de variables (car il y en a beaucoup !) Ce qui fait que l’envoi d’un fichier texte comme propose Top30 est exclu car cette solution est très exactement ce que je veux éviter (d’assigner chaque variables à une valeur à l’envoi et au retour).
Sinon, ma source n’a aucune utilité !!
Ma solution réside en 2 choses :
Une opération de mise en forme simple JSON (sérialisation sans passer en revue toutes les variables) et une opération de stockage de l’objet sérialisé brut sur le serveur web grâce à une fonction PHP.
Du coup, il suffit de le charger comme un fichier de faire l’opération de désérialisation de base pour pouvoir l’exploiter comme shareObject.
Concernant la norme WC3, il n’en est pas question non plus puisque le html n’est pas sollicité dans la mesure où l’on reste dans une application flash (php servant d’interface).
Pour conclure, la norme et les bonnes pratiques ne sont pas toujours les bons chemins à suivre pour obtenir la productivité par la performance ;-)
J’espère avoir été plus clair dans mon explication. Mon tors a été de penser que le code était assez explicite sur cette source qui est toujours d'actualité que ce soit pour flash ou pour AIR.
18 avril 2013 à 22:48
tu stringify ton json, tu stockes.
tu rapelles et tu parses.
C'est léger, rapide et surtout c'est a l'épreuve des balles^^.
Cordialement
23 mars 2012 à 10:40
request.data= new URLVariables( "name="+name+"&data"+data.toString() ) ;
23 mars 2012 à 10:38
Ne passes pas par la sérialisation Json...
Gardes directement les variables au format URL dans un fichier texte.
Un truc du genre:
// Ecriture des données de Flash vers PHP ////////////////////////////
var data : URLVariables= new URLVariables();
data.prenom = "Bill";
data.nom = "Boquet";
var name :String= "[URL]/monFichier.txt"
var request :URLRequest= new URLRequest("[URL]/writeData.php");
request.method = URLRequestMethod.POST;
request.data= new URLVariables( "name="+name+"&"+data.toString() ) ;
var loader :URLLoader = new URLLoader();
loader.addEventListener( Event.COMPLETE, onDataWrite );
loader.load(request);
function onDataWrite( $e:Event ):void{
trace("Données enregistrées");
}
// Récupération des données de PHP vers Flash /////////////////////////
var loader :URLLoader = new URLLoader();
loader.load( new URLRequest(name));
loader.addEventListener(Event.COMPLETE, onDataRead );
public function onDataRead( $e:Event ){
var data :URLVariables= new URLVariables($e.target.data) ;
for (var name :String in data ) trace( name, data[name] );
}
// Le PHP "writeData.php", toujours aussi simple...
<?php
$data= $_REQUEST['data'];
$name= $_REQUEST['name'];
file_put_contents( $name, stripslashes($data) );
?>
C'est ecrit à á volée, plus pour le principe que pour le bon fonctionnement. A vérifier !
23 mars 2012 à 09:49
Je ne suis pas persuadé que je me sois bien exprimé pour expliquer cette source.
Je réponds à Aerolyte, concernant le W3C. Effectivement c’est recommandé mais j’écris ce fichier en PHP via une liaison flash pour avoir une rétention de l’information et éviter une série de codage-décodage de la function JSON. Le fichier n’est pas énorme et évite des lignes d’instructions dans PHP.
Ainsi depuis mon appli AIR, je récupère directement mes données directement au format JSON comme si elles venaient d’être envoyées après par exemple plusieurs jours. J’évite ainsi des instructions pour l’écriture éventuelle d’un xml, d’un fichier binaire et un nouveau codage pour envoyer à flash et un nouveau décodage du côté réception flash.
J’utilise les shareObjects car le client est une sur une appli AIR et certaines informations demandent un cryptage et une rétention locale qui ne nécessite pas d’implémenter une base de données locale. Il se trouve donc que j’ai utilisé mon bout de code, issu directement de mon appli. Bien entendu, il n’est pas forcément utile d’utiliser un shareObject. Ici c’est juste parce que ça se présentait comme ça.
21 mars 2012 à 23:09
Pourquoi gardes-tu le SharedObject dans un tableau vu que tu n'énumères que que le premier élément de ce tablau ?
Moi j'ai juste l'impression que c'est plein de bon sentiments, mais la réalisation et l'utitilisation laisse à désirer....
Tu pourrais trés bien créer une classe, passer le nom du futur fichier à PHP, etc. etc...
Ca laisse à désirer, je mettrais seulement 6. C'est bien mieux que la moyenne des dernères sources mais c'est pas génial quand même.
Bonnce change et voir si tu améliores tout ca...
13 mars 2012 à 09:57
Concernant cette source je me demande si du coup il serait pas préférable d'utiliser le DOM storage pour les navigateur rècent. Ce qui est d'ailleurs conseiller par le W3C
Sinon je profite en peu de la visibilité de ta source pour faire appele a des compétences.
J'ai mis au point un nouveau modèle d'utilisation des bases de données hièrachique.
mais il me manque un peu d'aide d'expert en requète sql
tout est la: http://www.sqlfr.com/forum/sujet-NOUVEAU-MODELE-REPRESENTATION_1578316.aspx
Merci
12 mars 2012 à 23:57
Cordialement
29 févr. 2012 à 22:19
Peg'
29 févr. 2012 à 21:00
29 févr. 2012 à 12:26
Peg'
29 févr. 2012 à 05:00
effectivement j'utilise une classe déjà et sur la quantité de données je gagne plus de temps machine à sérialiser les données en JSON et d'envoyer à PHP qui va écrire en dur le contenu pour un prochain décodage en AS3, que de coder et décoder en XML. Effectivement pour peut de données ça n'a pas d'interret.
Pour tout te dire, j'ai eu besoin de cette fonction pour récupérer des données envoyée par flash à l'occasion d'un paiement en ligne. Comme le système de paiement est en https et géré par la banque, j'étais limité en taille de données à passer dans leurs variables. Avec cette méthode, je récupère les données à l'issue du paiement sans pertes et sans limite (256 niveaux maintenant) Sauf que pour ce cas de figure j'encode et écris les données depuis PHP (ce qui est un peut la meme chose).
Conclusion, gain de temps énorme, peut de ligne de codes et fiabilité puisque le fichier en dur est strictement conforme à la sérialisation JSON sans parler de la sécurité des données confidentielles !
Voilà, tu sais tout :-)
28 févr. 2012 à 19:53
Pourquoi ne pas envoyer directement tes données en XML ?
Peg'
27 févr. 2012 à 21:20
J'utilise cette façon de faire pour stocker une quantité de données en backup en dur.
27 févr. 2012 à 20:14
Merci beaucoup
Laurent