[PHP5] XML MENU
Teclis01
Messages postés
1423
Date d'inscription
mardi 14 décembre 2004
Statut
Membre
Dernière intervention
29 décembre 2012
-
26 mai 2006 à 19:06
malalam Messages postés 10839 Date d'inscription lundi 24 février 2003 Statut Membre Dernière intervention 2 mars 2010 - 5 juin 2006 à 14:33
malalam Messages postés 10839 Date d'inscription lundi 24 février 2003 Statut Membre Dernière intervention 2 mars 2010 - 5 juin 2006 à 14:33
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/37781-php5-xml-menu
https://codes-sources.commentcamarche.net/source/37781-php5-xml-menu
5 juin 2006 à 14:33
5 juin 2006 à 14:17
Ouaip, sinon essaye de tester différentes méthodes pour voir laquelle est la plus rentable.
Moi j'en ai aucune idée et j'ai rien sur moi pour le savoir.
5 juin 2006 à 13:50
=> l'autoload n'apprécie pas les tests dans la classe xmlmenu, détectant quelles classes sont activées. Pour XSLT notamment, si je le désactive, il cherche à le charger dans le répertoire class/ (je suppose que c'est le get_class () qui fait ça). C'est pour ça que je ne l'ai pas mis.
Pour toHtml, et les autres, en fait ouais, j'ai pris le parti de les surcharger uniquement pour XSLT vu que c'est la classe qui change le plus. En fait je voulais tester, faire un bench, pour voir si c'est plus rapide de ne surcharger que pour XSLT, etr de laisser les autres méthodes définies pour DOM chargé, ou de ne mettre vraiment dans ma classe abstraite que ce qu'il y a de commun, et de mettre la suite (le spécifique) dans le reste de la méthode, après appel à la méthode de la classe abstraite. Bref, j'avais peur que ça alourdisse, non pas le code, mais le travail de php.
Mais bon faut voir...
5 juin 2006 à 13:05
Bouhh.... l'autoload(), ca marche aussi avec les classes abstraites :p
Alors, c'est pas mieux à coder un truc comme ca ? =)
Enfin moi, je trouve ca plus joli =)
Ah si, y'a une erreur :p :p
Dans ta classe abstraite, tu mets par defaut les méthodes si XLST est activé par défaut ! Surtout pas ! Tu va surcharger tes méthodes pour rien. Je pense surtout à toHtml() !
Tu aurais du écrire ca dans ta classe abstraite :
public function toHtml($sType) {
if (false ( $type array_search($sType, $this -> aTypes))) {
return false;
}
}
Et le reste dans tes classes spécialisées comme suit : (ex avec DOM et XLST)
public function toHtml($sType) {
parent::__construct($sType);
// Suite du code propre à chaque classe
}
Ca c'est mieux :) Comme tu fais un array_search() dans toutes tes classes filles, autant la définir dans la classe abstraite :)
Voila voila :p
5 juin 2006 à 06:50
Merci :-) (à vrai dire, j'étais même parti sur une interface...avec).
4 juin 2006 à 22:03
Tu as fait 3 classes quasiment identiques. Jusque la tout va bien. Mais pourquoi ne pas en avoir fait une classe abstraite pour mieux gérer l'extension futur de tes classes ? Genre :
abstract abs_xmlmenu {
protected $aTypes = array ();
protected $sHtml = '';
protected $sXml = '';
public function __construct($sVersion null, $sEncoding null) {
$aTypes = scandir ('xsl');
foreach ($aTypes as $type) {
$this -> aTypes[$type] = strtoupper (substr ($type, 0, -4));
}
}
abstract public function defineNode ($sText, $aAttr = array (), $iId=0);
abstract public function defineLink ($sLink, $iId);
// etc...
}
Et comme ca, tu récupères tout déja de pré-fait, surtout au niveau du constructeur dont je t'ai donné en exemple ! Tu peux faire tes classes par la suite comme ca :
class xmlmenuhasboth extends abs_xmlmenu {
public function __construct($sVersion null, $sEncoding null) {
// Ce que tu veux comme modif
// Puis :
parent::__construct($sVersion, $sEncoding);
}
Et zoup, comme ca tout est unifié et c'est plus pratique :)
Ca t'évite de devoir re-écrire par exemple les méthodes genre defineLink() quand t'as le DOM, ou si t'as pas le dom tu surcharges la méthode :)
Voila voila pour le moment :)
30 mai 2006 à 13:28
cette fois, ça fonctionne aussi sans DOMDocument.
J'ai modifié en profondeur...
On a une classe "d'usinage" xmlmenu qui se lance via getInstance, et qui va instancier l'une des 3 classes, selon les cas :
- on a DOMDocument et XSLTProcessor
- on a DOMDocument mais pas XSLTProcessor
- on a ni l'un ni l'autre.
Les méthodes ne changent pas.
30 mai 2006 à 08:15
marci...je m'attaque aujourd'hui à se passer de DOMDocument...on verra ;-)
Uniqid, bonne idée, jamais utilisé ce truc, c'est l'occasion d'essayer!
Et oui, y a tjrs strtoupper, mais je stocke aussi ne nom du fichier "normal", lol...du coup, on appelle la méthode avec des majusciules, comme j'aime bien, et ça appelle le fichier correspondant, écrit normalement, lui ;-)
29 mai 2006 à 19:19
C'est bon ! Ca devient très bon même
Juste, pour la génération d'un nom de fichier XML temporaire (xmlmenu::toHtml()) je propose un
do{ $iCpt = uniqid(''); } while( file_exists('tmp_xml/tmp_xmllfile_'.$iCpt.'.xml') );
Et y'a toujours le strtoupper dans xmlmenu::__construct()
29 mai 2006 à 14:21
J'ai effectué quelques modifications (soulevées, essentiellement, par J_G) :
- plus de problème de nom de fichier sous un environnement linux/unix. Et les appels à la classe n'ont pas été modifiés, on utilise toujours LISTE, TABLE, ou tout nom de fichier xsl créé, mis en majuscule.
- j'ai viré le createTextNode ().
- Et la plus grosse modif : XSLTProcessor n'est plus nécessaire (voir mes commentaires dans le descriptif, et/ou en anglais dans la classe xmlmenu).
28 mai 2006 à 09:26
Teclis => tu me montreras ça lundi : je pense effectivement ajouter à terme une interface user friendly.
Sjon => Très bien merci, et toi ?? Ca faisait un moment!
J_G =>
- "Pourquoi ne pas utiliser :
$newElem = $this->doc->createElement('node', $sText);"
Les premiers exemples que j'ai utilisé fonctionnaient, pour le côté pédagogique, avec ces 2 fonctions. Du coup, j'ai pris cette habitude inutile en effet...lol. Je corigerai.
- "Attention à Linux où les noms de fichiers sont senssibles à la casse"
Je sais j'y ai pensé ce we, il faut que je corrige ça. J'au tendance à préférer les chaînes en majuscules, pour ce qui est des définitions de paramètres. Mais ce n'est pas compatible dans ce cas là, effectivement...
- "Tu pourrais m'expliquer ça STP... Car j'en ai marre de trouver des serveurs sans XSL..."
Ca reste à tester, je ferai ça lundi. Mon idée est que les XSL agissent comme les CSS. On peut lier une XSL directement à un flux XML comme on le fait d'une CSS pour un document HTML.
Donc, en réécrivant le flux XML à la volée, en lui assignant la XSL désirée (<xml link... />), et en incluant le flux transformée dans le document XHTML de départ (la page web), ça devrait fonctionner.
Bon, bnon dimanche à tous, et à lundi :-)
27 mai 2006 à 18:44
Comment allez vous au fait ? ...
27 mai 2006 à 15:26
par contre j ai un tit truc a te montrer ca te donnera une nouvelle interface possible et qui je pense est pas mal ^^
27 mai 2006 à 13:48
Ton code est élégant. C'est très didactique. Bravo!
Des p'tites remarques quand même (sinon c'est pas drôle)
Pourquoi ne pas utiliser :
$newElem = $this->doc->createElement('node', $sText);
Au lieu de :
$newElem = $this->doc->createElement( 'node' );
$sTexte = $this->doc->createTextNode( $sText );
$newElem->appendChild( $sTexte );
"Il faut donc contourner (à vrai dire ce n'est pas très complexe : il suffit de créer le lien entre le flux et le xsl, directement dans le flux)"
Tu pourrais m'expliquer ça STP... Car j'en ai marre de trouver des serveurs sans XSL...
$aTypes = scandir ('xsl');
foreach ($aTypes as $type) {
$this -> aTypes[] = strtoupper (substr ($type, 0, -4));
}
strtoupper ... Attention à Linux où les noms de fichiers sont senssibles à la casse! D'ailleur, ton script m'a généré une erreur par accès au système de fichiers. La cause : Les noms de fichier (LISTE ou liste, TABLE ou table) ou les droits en écriture dans les répertoires. Ca fera certainement partie de ta gestion des erreurs ;)
Dans xmlmenu::defineAttributes
$elem -> setAttribute ($attrName, $attrValue);
Attention... Les documents DOM ne mangent que du UTF8 ! Je proposerai au minimum :
$elem -> setAttribute ($attrName, utf8_encode($attrValue) );
Continu bien... A+
27 mai 2006 à 11:13
27 mai 2006 à 11:06
27 mai 2006 à 09:39
Mais je posterai ici les amélioratons, je pense.
Une gestion du XSLTProcessor est plus complexe, car cela veut dire qu'on ne peut pas utiliser cet objet et appliquer dynamiquement une XSL au flux XML. Il faut donc contourner (à vrai dire ce n'est pas très complexe : il suffit de créer le lien entre le flux et le xsl, directement dans le flux).
Mais ça perd de son intérêt ;-) C'est moins éducatif, quoi.
Il faut aussi gérer les erreurs (là, je n'ai implémenté aucune gestion des erreurs). Je ferai ça cette semaine.
Enfin, il FAUT de nouvelles XSL...! Parce que celles-là font pitié ;-)
Merci à vous deux en tous cas.
27 mai 2006 à 09:26
il serait même intéressant de gérer si XSLT et DOM sont chargés, et si ils sont présents pour les charger au cas où, via le constructeur non ??
enfin, c'est une suggestion de légère amélioration ;-)
(ça peut servir je pense dans le genre de configuration de Teclis01 ;-))
27 mai 2006 à 08:38
Ben c'est l'extension XSL, dans la doc, et l'objet s'appelle XSLTProcessor. Donc la dll xsl_php.dll je pense.
26 mai 2006 à 23:09
alors euh sauf erreur de ma part j obtient ceci ..
Fatal error: Class 'XSLTProcessor' not found in C:\wamp\www\classe\menu_xml\class\xmlmenu.cls.php on line 144
et en effet j ai pas trouver de class XSLTProcessor donc un oublie peut etre ou je sais pas snifff
En tout cas pour les resultats deja present dans la sources ils sont tres sympatoches ^^
Bravo a toi malalam!
Gros bisous grand fouuuu^^
26 mai 2006 à 21:04
Ton bin's m'a fait penser que ce pourrait être bien une classe permettant de de générer des menus à parir de fichiers xml :-)
mais c'est loin d'être fini.
En attendant, bonne soirée :-) Moi, c'est ciné (XMen 3) et boîte ce soir :-)
Bisous
26 mai 2006 à 19:06
ce dont vous revez, malalam vous l'apporte
(ca marche aussi avec la poste ^^)
Bon je testerais et j laisserais un tite note promis !