Création liste déroulante html avec PHP + XML

Création liste déroulante html avec PHP + XML - PHP - Programmation

Marsh Posté le 10-02-2009 à 14:03:01    

Bonjour à tous,
 
je suis actuellement en train de créer plusieurs listes dynamiques entre elles.
Il y aune liste pour les régions, une liste pour les départements et enfin une liste pour les villes.
 
J'ai utilisé le XML pour alimenter les futures listes HTML.
J'ai déjà créé deux fichiers XML pour la liste des régions et celle des départements.
Maintenant je voudrai afficher les données du fichier XML des régions dans une liste déroulante HTML.
 
J'ai trouvé un code sur le net que j'ai retravaillé pour arriver à afficher le contenu du fichier XML.
Mais le souci c'est que le code m'affiche bien les régions mais en revanche je n'arrive pas  
à faire en sorte qu'il les affichents sous forme d'une liste déroulante.
 
Si quelqu'un a une solution je suis preneur !
 
Voici la forme de mon fichier XML :  
 

Code :
  1. <channel>
  2. <region>
  3. <idRegion>1</idRegion>
  4. <nomRegion>Alsace</nomRegion>
  5. </region>
  6. <region>
  7. <idRegion>2</idRegion>
  8. <nomRegion>Aquitaine</nomRegion>
  9. </region>
  10. <region>
  11. <idRegion>3</idRegion>
  12. <nomRegion>Auvergne</nomRegion>
  13. </region>
  14. </channel>


 
Ensuite voici le code php qui permet de récupérer les données du fichier XML :  
 

Code :
  1. <?php
  2.     $fichier = "XML_region.xml";
  4.     // Ma propre fonction de traitement des balises ouvrantes
  5.     function fonctionBaliseOuvrante($parseur, $nomBalise, $tableauAttributs)
  6.     {
  7.         // En fait... nous nous conteterons de mémoriser le nom de la balise
  8.         // afin d'en tenir compte dans la fonction "fonctionTexte"
  10.         global $derniereBaliseRencontree;
  12.         $derniereBaliseRencontree = $nomBalise;
  13.     }
  14.  
  15.     // Ma propre fonction de traitement des balises fermantes
  16.     function fonctionBaliseFermante($parseur, $nomBalise)
  17.     {
  18.         global $derniereBaliseRencontree;
  19.         global $region;
  20.         global $id;
  22.         switch ($nomBalise) {
  23.             case "CHANNEL" :
  24.                 // nous quittons le bloc channel
  25.                 // nous pouvons afficher le titre de notre
  26.                 // liste de d'articles
  27.                 echo '<select name="choix_region">
  28.                       <option value="choix_region">Affiner par région</option>';
  29.                 // Et on oublie     
  30.                 $titre = "";
  31.                 $lien = "";
  32.                 break;
  33.             case "REGION" :
  34.                 // nous quittons un bloc region
  35.                 // nous pouvons afficher la région
  36.                 echo '<option value=' .$id. '>'. $region .'</option>';
  37.                 // et on oublie
  38.                 $region = "";
  39.                 $id = "";
  40.                 break;
  41.         }
  42.        
  43.         // On oublie la dernière balise rencontrée
  44.         // et tout le reste
  45.         $derniereBaliseRencontree = "";
  46.     }
  48.     // Ma propre fonction de traitement du texte
  49.     // qui est appelée par le "parseur"
  50.     function fonctionTexte($parseur, $texte)
  51.     {
  52.         global $derniereBaliseRencontree;
  53.         global $region;
  54.         global $id;
  55.        
  56.         // Nous n'affichons pas le texte ou lien directement
  57.         // nous attendrons de rencontrer la balise fermante
  58.         // et ainsi d'avoir tous les élements avant l'affichage.
  59.         // ATTENTION: Par défaut les noms des balises sont
  60.         //            mises en majuscules
  61.        
  62.         switch ($derniereBaliseRencontree) {
  63.             case "NOMREGION":
  64.                 $region = $texte;
  65.                 break;
  66.             case "IDREGION":
  67.                 $id = $texte;
  68.                 break;
  69.         }       
  70.     }
  72.     // Création du parseur XML
  73.     $parseurXML = xml_parser_create();
  75.     // Je précise le nom des fonctions à appeler
  76.     // lorsque des balises ouvrantes ou fermantes sont rencontrées
  77.     xml_set_element_handler($parseurXML, "fonctionBaliseOuvrante"
  78.                                        , "fonctionBaliseFermante" );
  80.     // Je précise le nom de la fonction à appeler
  81.     // lorsque du texte est rencontré
  82.     xml_set_character_data_handler($parseurXML, "fonctionTexte" );
  84.     // Ouverture du fichier
  85.     $fp = fopen($fichier, "r" );
  86.     if (!$fp) die("Impossible d'ouvrir le fichier XML" );
  88.     // Lecture ligne par ligne
  89.     while ( $ligneXML = fgets($fp, 1024)) {
  90.         // Analyse de la ligne
  91.         // REM: feof($fp) retourne TRUE s'il s'agit de la dernière
  92.         //      ligne du fichier.
  93.         xml_parse($parseurXML, $ligneXML, feof($fp)) or
  94.             die("Erreur XML" );
  95.     }
  96.    
  97.     xml_parser_free($parseurXML);
  98.     fclose($fp);
  99. ?>


 
 
J'espère que j'ai été suffisament clair et je vous remercie d'avance pour votre aide.

Reply

Marsh Posté le 10-02-2009 à 14:03:01   

Reply

Marsh Posté le 10-02-2009 à 14:05:45    

Hello,
 
Question: pourquoi utiliser un fichier xml ? Est-ce une contrainte qui t'es imposée ?
Si tu peux faire autrement, pourquoi ne pas passer par une BDD qui te simplifierait le requetage, et qui reste tres simple a mettre a jour...


---------------
http://poemes.iceteapeche.com - http://www.simuland.net
Reply

Marsh Posté le 10-02-2009 à 14:16:50    

Je me suis dit que mettre ces infos dans une base de données surchagerait ma base (26 régions, 95 département, 36000 villes, approximativement) et c'est donc dans un soucis de légèreté que j'ai choisi cela.
Vu que aussi, au niveau mise à jour, les régions et département ne sont pas en passe de changer je trouvais cette solution plus intéressante mais après il est vrai que toutes ces données vont surcharger mon serveur!
 
Maintenant que cela est dit, que penses-tu être la solution le plus adapté et la moins lourde en terme de traitement et de poids ?
 
Merci

Message cité 1 fois
Reply

Marsh Posté le 10-02-2009 à 14:30:07    

D'accord avec toi que ces données ne vont pas bcp changer.
 
Mais le surcout de lire le fichier a chaque fois pour aller denicher les infos dont tu as besoin est a mon sens pas utile.
Une BDD correctement constituée t'eviteras la lecture et le parcours du fichier a chaque fois que l'utilisateur fera une recherche.
 
table regions : id, region_nom
table departements : id, region_id, departement_nom
table villes : id, ville_nom
 
Tu peux facilement en tirer ce qu'il te faut pour populer tes listes dynamiques


---------------
http://poemes.iceteapeche.com - http://www.simuland.net
Reply

Marsh Posté le 10-02-2009 à 14:32:39    

Donc pour toi, c'est plus optimisé d'utiliser une base de données ?
 
Si tel est le cas, je m'y mets !
 
Je te remercie pour ton aide et ta proposition.

Reply

Marsh Posté le 10-02-2009 à 15:45:04    

si tu utilises SAX pas trop de soucis de performance (SAX est séquentiel), mais franchement la syntaxe est pas terrible...

Reply

Marsh Posté le 10-02-2009 à 16:07:47    

axelandre a écrit :

Je me suis dit que mettre ces infos dans une base de données surchagerait ma base (26 régions, 95 département, 36000 villes, approximativement) et c'est donc dans un soucis de légèreté que j'ai choisi cela.

S'il suffit de 36000 enregistrements pour surcharger ta base alors t'as un gros problème de serveur. Même access est capable de s'en sortir sans lenteur avec cette quantité de donnée.
Si on prend l'exemple de mysql, on peut aller sans crainte jusqu'au milliard de lignes, à condition d'avoir assez de place sur le disque ;) , et d'autres logiciels sont meilleurs que mysql sur ce genre de volumes.

axelandre a écrit :

Vu que aussi, au niveau mise à jour, les régions et département ne sont pas en passe de changer je trouvais cette solution plus intéressante

Ca par contre c'est une raison valable.
A noter que pour les données qui ne changent jamais, mysql propose les tables de type "archive" ("update" impossible donc table optimisé pour la lecture)

axelandre a écrit :

mais après il est vrai que toutes ces données vont surcharger mon serveur!

tu veux dire en les mettant dans des fichiers je supposes. ;)  
 

axelandre a écrit :

Maintenant que cela est dit, que penses-tu être la solution le plus adapté et la moins lourde en terme de traitement et de poids ?
 
Merci

Sans hésiter, je dirais que oui mais pas forcément pour des questions de vitesse.
 
Pour la base de donnée côté vitesse :

  • Avec un fichier tu perd le temps d'ouverture et de fermeture à chaque fois alors qu'avec une base de donnée, tu auras surement récupérer d'autres infos et tu seras donc déjà connecté.  
  • Même en connaissant le département, tu seras obligés de parcourir le fichier en entier alors qu'avec une base de donnée tu ne reçois que les villes du département choisit (90 fois moins de données donc)


Contre la base de donnée côté vitesse :

  • En fonction des réseaux et des serveurs, le gain ci-dessus peut être annulé par la différence de vitesse entre le disque dur et le réseau. Remarque valable uniquement si le serveur php et le serveur mysql ne sont pas sur la même machine.


Au final, il est difficile de dire que telle ou telle solution sera meilleure côté vitesse dans tous les cas. Par contre la facilité de traitement des données qui sont mises dans la base contre balance généralement les risques de lenteur (et c'est surement pas un select sur la table des villes qui mettra le serveur à genoux). ;)  
Par exemple si on pense en terme d'intégrité des données. Si t'as la liste des villes dans ta base, tu peux dire que telle personne habite dans la ville d'id 32. Ensuite quand une ville change de code postal ou de nom, il te suffit de modifier l'enregistrement de la ville et tout ceux qui y habitent profitent automatiquement du changement.
Si tu as les villes dans un fichier, alors tu seras obligé soit de dupliquer les données dans la base au fur et à mesure des besoins ce qui ferait double emploi, soit de mettre le nom de la ville et le code postal dans la base pour chaque personne/adresse. Dans ce dernier cas, si une ville change de nom, alors tu es obligé de modifier manuellement tous les enregistrements en espérant ne pas en oublier.
 
C'est pour ça que c'est sans hésitation que je te conseille de stocker ces données dans la base.

Reply

Marsh Posté le 10-02-2009 à 20:51:00    

d'accord avec omega2
 
:D


---------------
http://poemes.iceteapeche.com - http://www.simuland.net
Reply

Marsh Posté le 11-02-2009 à 14:54:02    

Je ne comprends pas le stockage de donnée par xml  [:pingouino]  
Parser un XML revient à faire un full scan sur une table en DB, soit la pire chose qui puisse arriver.
 
Les seules raisons d'utiliser de l'XML sont pour moi :
-la communication entre 2 systèmes hétérogènes
-l'edition de fichiers de config par des non-dev (et encore, un .ini c'est ptet mieux si de toute façon c'est ouvert par un éditeur qui ne valide pas l'xml)
 
Pour le reste -> db

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed