TRANSFERT DE DONNÉES FLASH <-> PHP - PETITE SUBTILITÉ AVEC JSON (AS3 - PHP5)
fedebul
Messages postés
129
Date d'inscription
vendredi 17 mars 2006
Statut
Membre
Dernière intervention
27 février 2012
-
27 févr. 2012 à 20:14
aerolyte Messages postés 465 Date d'inscription mardi 17 avril 2007 Statut Membre Dernière intervention 4 mai 2013 - 19 avril 2013 à 14:38
aerolyte Messages postés 465 Date d'inscription mardi 17 avril 2007 Statut Membre Derniè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.
https://codes-sources.commentcamarche.net/source/54097-transfert-de-donnees-flash-php-petite-subtilite-avec-json-as3-php5
https://codes-sources.commentcamarche.net/source/54097-transfert-de-donnees-flash-php-petite-subtilite-avec-json-as3-php5
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