Bonjour tout le monde,
 
Je suis actuellement en train de réfléchir et de me documenter pour faire un site multilangue avec forum pour un logiciel qui va sortir l'année prochaine (je suis stagiaire...). Je voudrais pouvoir gérer les news et le menu du site par des fichiers XML interrogés via PHP. Je ne sais pas si question ergonomie (temps de réponse...) et question sécurité le XML est approprié, mais je vois bien le menu XML du genre:
 
<MENU>
<MENU1 lang='fr'>
1er tome
<M2 lang='fr'>
1er chapitre
</M2>
</MENU1>
<MENU1 lang='en'>
1st book
<M2 lang='en'>
1st chapter
</M2>
</MENU1>
<MENU1 lang='fr'>
1er tome
<M2 lang='fr'>
2nd chapitre
</M2>
</MENU1>
 
Pareil pour les news et la gestion des langues. Mais est-ce approprié pour ce que je vais faire et comment réduire les trous de sécurité qui peuvent exister (hormis ceux du php et du contrôle des variables retournées par le client) ? Où dois-je mettre les fichiers XML pour garantir une intégrité la plus grande possible et quelle sécurité dois-je mettre autour de ces fichiers ?
 
Merci de vos réponses.

Une petite précision, je suis débutant en PHP et XML (bon, je connais un peu quand même) et même si mon surnom (que les autres me donnent...) laisse penser que j'en sais beaucoup, et bien non, je n'ai pas la science infuse en PHP et XML. S'il vous plaît, n'utilisez pas trop de termes ésothériques, que seuls les programmeurs de haut vol comprennent.
 
Merci

d'autres questions car ça m'intéresse pour bientôt...
 
- comment est-ce PHP gère le XML ?
- si ton menu devient long, ne serait-il pas intéressant d'avoir un menu par langue ?
 
j'éviterais d'avoir 36 éléments menu: menu1, menu2, menu3,... mais type les avec des attributs genre <menu @type="1"> voire carrément <menu @type="livre|chapitre|...">
 
ainsi que j'éviterais d'avoir  

mais

voire même

c'est plus propre je trouve.

Moi je virerai sous-menu pour avoir un truc du style

 
comme ca dans ta dtd, t'as uniquement menu et non menu, sous-menu, et sous-sous-menu. Ainsi t'es pas limité au nivo des sous menu (pas besoin d'en rajouter dans la dtd).  

C'est "autorisé" ce genre de manière de faire?

c'est autorisé oui, mais c'est pas super propre...
 
imaginons que l'auteur du menu se plante dans l'ordre des labels et c'est la foirade totale... (et en plus, une erreur peut être vite faite: confondre 2 languages comme le portugais et l'espagnol (je parle pour moi))

pas super propre ?!! c vré que si t'as 5 sous menu vo mieux faire 5 balises différentes, ca c super propre !

et j'ajoute que foutre des balises sousmenu, soussousmenu c vachement pratique pace que le mec s'il atteint la limite (défini dans la DTD, il a dans le cul, il sera obligé d'y retoucher (dans le meilleur des cas).
 
et pis il n'y a absolument rien qui différencie un menu d'un sous menu.

c'est un point de vue...
je prends le XML comme structure de données... autant qu'elle soit propre et précise.
 
comme le XML n'a pas pour but d'être réduit en taille afin d'être transmis, autant le structurer et pas l'optimiser en virant toutes les balises/attributs intermédiaires.
 
si je devais prendre ta solution, j'aurais ajouté un "@langue" à "label" histoire de le spécialiser.

ben ouais, j'ai deja vu des fichiers de conf hyper crade ie impossible a traiter correctement. Obligé de me retaper toute la génération.  
 
XML se veut aussi récursif et générique dans un sens, ce qui est super pratique lorsque tu veux utiliser des processeurs derrière.
 
Mais c vré que si tu prends XML comme une structure de donnée ou il n'y a rien derrière je dis pas. Mais j'en vois pas l'intérêt.
 
 

j'ai dû traiter des fichiers XML dont la DTD était vraiment pourrie... des dizaines d'éléments dont juste un petit numéro variait dans le nom... vraiment crade... bref
 
pour en revenir au post initial, nos solutions ne sont pas hyper éloignées... mon "sous-menu" peut très facilement devenir un "menu"  ce qui permet une certaine récursivité. c'est au développeur à pouvoir s'en sortir
 
par contre, si qq'un pouvait revenir sur ma question de comment gère-t-on du XML avec PHP ce serait zouette (dwnld en cours de la doc PHP)
 

 
a toi aussi, c bon je ne suis plus seul :-)
 
moi je suis quelqu'un qui aime la généricité et la simplicité dans son état pur

pas trop quand même la simplicité

et (x)thml, ça vous dit qqch ??
 
<ul>
<li>...  
 <ul>
 <li>..</li>
 <li>..</li>
 </ul></li>
<li>...</li>
</ul>
 
non ? bon c'est pas grave. Pourquoi faire simple

ce n'est pas mieux si il doit y avoir process pour sélectionner les données de la bonne langue...

Bonjour à tous, je vois que vous commencez à vous défouler sur mon problème (tant mieux pour moi) et merci de toutes vos précisions pour le code XML que je vais utiliser. Mais je vais revenir à mes questions du début:
- Est-ce que le menu (d'un site) en XML est approprié pour afficher l'arborescence du site et les liens et les pages à afficher.
<MENU lang='fr'>
 <LABEL>1er tome</LABEL>
 <LINK>page_1_tome</LINK>
 <MENU>
  <LABEL>1er chapitre</LABEL>
  <LINK>page_1_chap</LINK>
 </MENU>
</MENU>
 
- De plus, quelle sécurité dois-je mettre autour des fichiers XML pour garder une intégrité totale des fichiers et pour éviter que d'autres personnes non autorisées via Internet (des pirates par exemple) les détruisent où les corrompent ?
 
Merci encore de votre intérêt

Une autre question:
 
Est-il concevable d'un point de vue développement et ergonomie de développer le site (multilangue) en php avec des pages XML (news, menu, pages autres) qui soient en plusieurs langues? Je m'explique:
Est-ce que XML est mieux qu'une simple base de données pour gérer un site multilangue qui donnent quelques infos sur un produit, des news et avec un forum de discussion (avec sa propre base de données) en sachant que l'administration doit être la plus faible possible (de l'ordre de 1 jour/homme par mois et je parle seulement de l'administration...)et que les mises à jour de news et autres pages ne seront pas très fréquentes (page: tous les mois, news: toutes les quinzaines). Mon choix est-il judicieux dans ce cas ?

a ta place je me contenterai d'une db.
 
En ce qui concerne l'administration (si 1 homme/jour/mois), ben ça dépend complétement du fait comment tu vas organisé ton site et ta base. Si tu automatise certains traitement et d'autres non.
 
 
XML est parfait pour écrire des fichiers de conf, décrire des structures, pour stocker c autre chose.
 
A la limite, pourquoi pas ne pas stocker dans une bd, plusieurs feuilles XML (genre news, user, lang, etc...). C'est une solution comme une autre. A ta place, je me contenterai d'une simple bd. Je vois pas ce que XML pourrai t'apporter d'autre (dans ton cas).
 

Je pensais que les fichiers XML m'apporteraient d'une part la possibilité de gérer les langues (pour les news et le menu) et d'autres part une certaine flexibilité de rajout de noeuds (pour le menu, mais aussi les news, les pages).
De plus, les fichiers XML sont très facilement réalisables (ce sont des fichiers texte après tout) et compréhensibles (s'ils sont bien faits).
Donc pour changer le menu ou rajouter une news, il suffit de remplacer le fichier en question ou d'en rajouter un (pour les news). Et tout ceci sans problème d'administration de bd et de remplissage de cette bd, sans parler du développement des pages de saisies nécessaires au remplissage de la bd, et en prime toute la sécurité à mettre en place autour des écrans de saisies que je devrai faire pour remplir la bd.
 
Je le voyais comme ça... Une gestion des sessions et du site en php avec passage des paramètres (langues, sessions, autres...)d'une page basée sur du XML à une autre page (elle aussi basée sur du XML), des news et un menu en XML.
 
Je pensais et je le pense encore que le XML me facilitera pour beaucoup de choses.
 
   pour les réponses

la boîte pour laquelle je bossais créait des sites web multilangues dont les données n'étaient stockées qu'en XML... un attribut lang de l'élément principal permettait au process de création du site de choisir le document de la langue désirée. (il y avait un process qui gérait les liens interdocuments-interlangues aussi)
 
c'est pas bête de stocker le contenu de son site en XML. nous on transformait méchamment le contenu à travers du Java et XSL... (ajout de fonctionnalités automatiquement)
 
on avait aussi une DTD et une API qui jouait le rôle d'une DB pour les petits volumes qui ne nécessitaient pas l'install d'un SGBD.
 
mais on n'avait pas de contraintes de demande à la volée de documents, le site web était généré et ensuite déposé sur le serveur.
 
c'était cool

Un truc a vérifier au sujet du xml : est ce que comme pour le xhtml les caractères accentués doivent être transformés?
Bon, déjà vu que les < et > servent a délimité les balises de début et fin de noeud, alors ca doit être le cas au moins pour ces deux là.
De plus, une erreur humaine est vite arrivé alors pour moi, dire au client "vous modifiez les fichiers a la main", c'est pas une très bonne idée.
Pour ton problème de sécurité au niveau des fichiers, tu peux déjà être rasuré pour un point : a part si sur le serveur web t'as des pages qui modifient/créent ou supriment des fichiers, t'as pas de risque de sécutité de ce côté. Par contre, il reste le problème des droits d'accés au répertoire web depuis le réseau par les dossiers partagés et depuis la machine elle même. il faut donc que le dossier du site web ne soit pss partagé ou alors partagé mais avec un mot de passe pour y accédé et que monsieur n'importe qui n'ai pas le droit de ce loguer sur la machine avec un compte lui donnant droit de modification/supression a l'intérieur du répertoire en question.

Normalement, selon la manière dont on déclare le fichier XML, les accents et autres caractères spéciaux sont acceptés.
Pour en revenir au remplissage des fichiers, il se fera par l'administrateur qui aura demandé au client un format bien précis.
Prenons un exemple: pour les news, il faut un titre, un résumé, un corps de texte, une période de validité, une ou plusieurs images le tout pour une langue. Libre à lui de les traduire en plusieurs en respectant cette "casse". Soit le schéma XML est donné directement au client en lui expliquant la chose (bien sûr), soit ce sera à l'admin de le faire.
Mais je pense qu'ainsi, on garde une certaine souplesse pour les langues et les news sans se préoccuper d'une gestion de base (de requête d'insertion dans les tables avec jointure et de MCD (modèle conceptuel de données)). De plus, une partie des liens sera gérée par le menu et les news (les deux en XML).
Pour le problème d'autorisation d'écriture, seul l'admin sera habilité à changer le contenu du site.
Le client ne pourra pas poser ces données ou fichiers tels quels dans un répertoire (qu'il faudrait sécuriser...). Le client les envoie et l'admin les dépose dans les dossiers appropriés et c'est tout. Pas d'écrans de saisie, de paramètrages...  
Cela se veut simple... Mais faut voir...

Simple pour le programmeur, c'est sur.
mais heu ... je vais jouer l'avocat du diable : l'administrateur, il part jamais en vacance?
(bon, ok, je me doutes que vous avez prévus la présence d'un remplacant)
 
Bon, je redeviens sérieux : Pour avoir bosser pendant trois ans sur un programme dont certaines parties (heureusement très rares) étaient géré de cette façon, je peux te dire que ca devient vraiment chiant a force de devoir recevoir les fichiers, les passer une fois en test pour vérifier leur validité, chercher les erreurs à l'intérieur pour dire au client ce qui va pas et attendre enfin un fichier valide.
Ca me prenait peut être qu'une heure par semaine, mais a chaque fois, j'avais l'impression de perdre une heure vu que c'était pas du tout automatisé.
 
J'espères que vous aviez déjà pensé à ce problème là.

j'y ai pensé mais le site est vraiment assez modeste dans le sens circulation de l'information et renouvellement des news. C'est essentiellement un site de démonstration de ce que l'on peut faire avec Internet et un très bon exercice pour moi (qui suis en train de faire un stage mémoire car en dernière année d'école d'ingénieur (en agriculture)).
Le site sera un site de vitrine pour un logiciel avec mise à disposition de patchs de correction (on pense déjà à l'avenir...), avec une partie de mutualisation de ressources téléchargeables (gérées par un CGI indépendant du site), des news sur quelques domaines et des forums de discussion.
Je dirai rien de bien méchant, juste de quoi montrer qu'un site serait la cerise sur le gâteau pour le logiciel en cours de développement.
Ce serait une démonstration qui marcherait (bien même...) et qui serait laissée telle quelle si le développement d'un site plus costaud n'est demandé.

Ha ok, si c'est jsute pour une maquette de site, alors t'as raison de pas te prendre la tête pendant 6-12 mois a imaginer un truc qui réponde au moindre petit besoin pouvvant subvenir plus tard.
Mais si le site doit pas mal évolué plus tard, ca serait bien que tu penses dès a présent a une gestion de module. Ainsi la rajout d'une section "moduiification des menu" serait juste quelques fichier a rajouter et un fichier (xml ou autre) a modifier. De plus, avec une gestion de module bien pensé, il sufit de virer les références a un module pour le désactivé et empécher qu'on ne l'utilise.

Voila, c'est l'idée que j'avais avec le menu en XML car ce dernier permet de donner l'arborescence du site et de donner les liens qui vont avec cette arborescence. Ajouter un module: ce serait ajouter un fichier XML, un fichier PHP et un noeud supplémentaire au fichier du menu en XML.
Après pour faire une interface de saisie de news et de modification de menu, on peut voir...

Après un certain temps de recherche sur le Net, sur le forum hardware.fr et sur php.nexen, je n'ai pas trouvé ce que je cherche. Voila, je m'explique:
 
J'ai un serveur IIS (je sais, c'est une honte...) avec PHP 4.3.0 installé et je fais mon site en php avec du XML. Le HIC, c'est que je n'arrive pas à parser du XML avec du XSL (côté serveur car je veux savoir ce qui va s'afficher). Je ne dois pas avoir les bonnes fonctions en php pour parser du XML et du XSL.
 
Voici ma fonction:
 
function xsltProcess($pageXml, $fichierXsl)
{
    $pageXsl = fread(fopen($fichierXsl,"r" ), filesize($fichierXsl));
    if (xsltClientProcessOK()==false)
    {
        ob_start();
        xmlTag();
        print $pageXml;
        $pageXml = ob_get_contents();   // Récupérer la sortie texte
        ob_end_clean();
        $moteur = xslt_create();        // Initialiser le processeur XSLT
        $arguments = array('/_xml' => $pageXml, '/_xsl' => $pageXsl);
        $pageXhtml = xslt_process($moteur, 'arg_xml', 'arg_xsl', NULL,$arguments);
        xslt_free($moteur);             // Libérer le processeur
        print $pageXhtml;
    }
    else
    {
        header("Content-Type: text/xml" );
        xmlTag();       // En tête XML
        xmlXslTag();    // Lien XML vers une feuille XSL
        print $pageXml;
    }
Aucune erreur n'est renvoyée...juste du blanc...
 
Y a t'il quelqu'un qui pourrait m'aider, cela m'avancerait beaucoup.
 
Comment parser en php du XML et du XSL (côté serveur) sous IIS ?
 
  Merci

Même en tapant xml dans la zone de recherche de nexen?
Par ce que des fonctions telles que xml_parser_create semblent indiquer qu'il y a ce que tu cherches.

Bonjour à tous,
 
Voilà quelques temps que j'essaies de parser du XML avec PHP, mais rien à faire. Je ne vois que du blanc. Je ne sais plus quoi faire...  
Je suis pourtant la doc que je trouve sur internet mais rien à faire. Il y a des fois des erreurs qui me désigne le xslt_process ou xslt_create mais j'ai pourtant installé sablotron et expat.
 
Que faire alors ?
 
Si quelqu'un a eu le même genre de problème et a réussi à le surmonter, je suis preneur de ses conseils...
 
   Merci d'avance de vos réponses  

sois plus précis car comme ça on ne peut pas t'aider...
 
pour ma part quand j'avais des documents vides sans erreurs c'était souvent à cause de mon expression de départ dans la page XSL qui n'était pas correcte.

Bon, j'ai tout réinstallé depuis le début (php4.3.2 + easyphp) et oh miracle, cela marche. Il y a des fois où les voies de l'informatique sont impénétrables...  
Je ne sais toujours pas pourquoi... Mais bon, maintenant je vais pouvoir continuer mon développement...
 
J'aurai très certainement l'occasion de vous poser encore des questions.  
 
   Merci à ceux qui m'ont répondu.

drapal de le mort  

C'est encore moi, et j'ai toujours des problèmes (à la con, il faut le dire...)
Je développe sur windows XP Home et j'ai installé easyphp 1.6. J'essaie toujours de parser du XML et du XSL avec PHP.
voici mon fichier test2.php:

 
mon fichier test.xml d'essai:

 
mon fichier test.xsl d'essai:

 
Le tout dans le répertoire C:\Program Files\EasyPHP\www\essais.
 
Et voici les erreurs retournées:

 
Je ne comprends pas pourquoi le serveur essaye de chercher le fichier test.xsl dans le répertoire apache de easyphp. Que faut il que je fasse pour remédier à cela?
 
Merci de vos réponses

Progblème de réglage?
Va poser la question sur le site d'easyphp, on sait jamais.

Bonjour à tous ,
Cela fait une journée que j'essaie de faire marcher apache 1.3 et php 4.3.2 sur Windows XP Home en suivant les explications du site http://www.phptools4u.com/articles [...] icle=3&p=1 (j'aimerai enfin pouvoir parser du XML et du XSL avec du php... ...). J'arrive les fichiers qui se trouvent dans le site via http://localhost/essais/, le service tourne donc mais en cliquant sur un des fichiers pour l'afficher, j'ai une boîte de dialogue qui s'affiche pour télécharger le fichier...
Que faut-il faire ? Cela fait plusieurs jours que je cherche et que je fouine partout sur le net et je commence à désespérer.
 
Merci de vos réponses qui pourront consoler un débutant

J'ai trouvé mon erreur (très c...e !), j'avais oublié un d à httpd...
Ca marche sauf que la fonction xslt_create() n'est pas reconnue... Bref, encore du boulot...

 
implementer depuis la version 4.03 de PHP .....
mais il faut compiler apache avec le support xslt --enable-xslt.    
a mon avis ton probleme est la .....
pour le verifier .. un petit phpinfo()    

Merci du conseil,
 
J'ai regardé et j'ai DOM/XSLT et DOM/XML enabled, libxslt Version 1.0.23, libxslt compiled against libxml Version 2.4.28, XML Support active, XML Namespace Support active et EXPAT Version 1.95.2 donc je devrais avoir les fonctions nécessaires dont xslt_create().
J'ai extension_dir qui pointe sur mon répertoire PHP\extensions\ et include_path sur PHP\PEAR\. Dans le répertoire extensions, j'ai le fichier php_xslt.dll (32Ko) et dans PEAR je n'ai rien.
Pourtant lorsque je fais appel à la fonction xslt_create, que du blanc et sur le journal d'erreur de Apache, il me met cette erreur: Call to undefined function:  xslt_create().
Je ne dois pas avoir apparemment la bonne librairie... Mais pourtant, il me semble que (d'après la doc de nexen) je devrai pouvoir utiliser cette fonction.
 
Que dois-je faire?    
 
Merci

..... la ca craint .....  
essaie de poster dans un newsgroup peut-etre