Bonsoir à tous,
 
Il existe beaucoup de solutions template type phplib, smarty ou autre... De l'autre côté il y l'utilisation de XML pour le contenu qui me permettrai de séparer totalement le contenu du code et du design.
 
Mais je me demandais si en surcharge serveur (et donc lenteur du site) le fait de parser un fichier XML à partir de PHP n'est pas lourd ? Surtout que le parsing se réalise à chaque fois qu'une personne lis la page.
Ca reviens a chaque fois à lire un fichier, comparé à des solutions comme smarty où il n'y a pas de parsing de fichiers autres que celui executé puisque tout est dans le meme fichier.
 
Je précise que je ne souhaite pas réaliser de fichier "cache" du type .html résultant de php+XSLT une seule et unique fois.
 
Donc est-ce vraiment lourd comme solution au point de voir son site lent ou bien cela reste il exploitable voir mieu ? Si vous avez déjà utilisé cette solution j'aimerai votre retour d'expérience merci.
 
J'espére avoir pu me faire comprendre :s. Merci à vous !

hello, j'ai utilisé recement la transformation xslt et la génération de documents pdf à partir de docbook. c'est effectivement lourd... mais j'ai bossé sur des fichiers relativement lourds...
 
si tu ne souhaite pas faire de cache, et que tes documents sont légers, alors ça peut être viable. mais le mieux c'est de tester

A priori mes fichiers XML devraient contenir le texte classique d'une page et aussi du code php (du moins des variables) qui seront traités au moment du parsing.

Si c'est pour de l'intranet, tu peux laisser le client (navigateur internet) faire lui meme le parsage/interpretation XML/XSLT.

Le XSL ça pue du gland (c'est pas pratique et ça devient rapidement complètement imbitable).
 
Le XSL client-side, ça pue encore plus du gland.

Je plussoie allègrement    
Et pour tout dire j'étends même le concept "pudugland" au XML.  
Pour moi le seul endroit ou utiliser du XML peut être interessant c'est pour "normaliser" des echanges entre 2 applications .
Mais le XML comme solution de stockage de données, perso je vomis dessus ( et encore je ne parle pas des problèmatiques de recherche au sein des fichiers ( et le premier qui dit XQuery ... ))

Pour avoir testé le xsl côté serveur et smarty, je trouve que smarty est bien plus pratique et dispose de plus de fonctionnalités.
Poir le XSL côté client, je rejoins Masklinn : c'est pas terrible car ça consomme aussi pas mal de ressources et le rendu n'est pas garanti identique comme celui prévu par l'auteur du site (même genre de pb que le css).

 
à la base, c'est bien pour ça qu'il est prévu. Mais comme toute bonne "invention", elle a été détournée

En admettant que je me passe de XSLT mais que je n'utilise que php qui parse un fichier XML de données.
 
Je me demande donc si c'est mieu de faire un accés à a la base de donnée en permanence ou bien de mettre mes données dans un fichier XML et de le parser donc aucun accés base de donnée, le fichier XML fait office de fichier cache. De plus internationnaliser l'application avec des fichiers XML peut être bien.
 
Concrétement le parsing est il lourd pour un serveur ?
 
Edit: Je précise que je persiste dans la solution du XML tout simplement car je souhaite donner un accés à mes pages à des developpeurs tiers, donc un fichier XML est parfait, ils n'auront qu'à parser le fichier. Je peux bien evidemment faire ma solution php/base de donnée et à coté créer le fichier XML pour les developpeurs tiers mais si ce fichier XML peut aussi remplacer ma DB pour certaines données pourquoi pas... ca limiterai les accés en base de données sur les données plus ou moins fixes.
Je précise que chaque fichier XML par page ne doit pas contenir plus de 20/30 entrées.
 
Merci

Comme anapajari l'a dit précédemment, le xml comme méthode de stockage, c'est pas terrible du tout (style sqllite : bd en xml). Si t'as besoin d'effecteur des recherches de données, ça va ramer. Si y'a besoin d'ouvrir ton appli à des développeurs, le mieux est de mettre en place des services web, qui eux, seront en xml (je pense à une architecture REST ou plus lourd, SOAP). Si c'est juste pour publier des données, tu peux te contenter de RSS.
Mais dans tous les cas, ça ira toujours plus vite de faire un extract de ta bd et de packager le tout dans du XML plutôt qu'à chaque fois, de parser du xml.

er... what?

Le plus rapide pour des données qui ne changent quasiment jamais, c'est un fichier php généré (quand c'est nécessaire) à partir d'un format plus ouvert et couplé à un système de cache d'opcode. (plus besoin de la partie analyse avec ça)
Le second système le plus rapide, c'est d'avoir un répertoire virtuel placé dans une partition virtuelle stocké en mémoire vive (mais il faut penser à la reremplir à chaque lancement du serveur et donc prévoir un stockage sur une partition physique) ce qui évite tous les accés disque dur (à noter que ça réduit l'espace mémoire vive disponible pour le reste donc il ne faut pas en abuser)
Après entre un fichier .ini, un fichier texte de type "valeur=texte", un fichier .xml et un stockage en base de donnée, il faut tester pour savoir ce qui est le plus rapide et le plus adapté en fonction de chaque cas (ce qui peut changer avec la monté en charge, le nombre de valeur à stocker, la façon de récupérer les données (une par une ou tout à la fois) et le matériel utilisé) il n'y a pas de vérité absolu en la matière.

Merci bien pour tout vos conseils ! Ils m'ont beaucoup aidé.
 
Je n'ai pas encore choisi de solution mais je vais sans doute rester à coder de manière classique
Le systeme de template en php ne me plait guère due à un double code à maitriser. Je vais donc me contenter de coder proprement (le code principal en premier puis uniquement les $var mélangées au code html de ma page) et gérer l'internationalisation avec des constantes (DEFINE). Quant à mon ouverture aux tiers je générerai au besoin mes fichiers XML à l'image d'un flux RSS.
 
C'est bien dommage d'en rester à ca quand on voit ce que le couple php, xml, xsl ou encore la solution en asp.net d'utiliser des fichiers en code behind pour séparer le code du design peut proposer.
 
Edit: Ce qui suit n'est plus vraiment utile j'ai décidé de passer de vista à xp donc problème réglé.
Un petite question pour ceux qui auraient déjà testé, je souhaitais adopter comme solution d'internationalisation Gettext. Malheureusement le logiciel permettant de créer des fichiers de langues, poedit en l'espece ne semble pas compatible Vista. Auriez vous un tutorial permettant de créer/compiler manuellement (il me semble que ce sont des fichiers compilés mais pas sur...) ce genre de fichier ? *.po ou *.mo sur linux ou win.
Ca m'a l'air bien plus interessant que d'utiliser des constantes, mais la prise en main n'a pas l'air très facile d'autant plus qu'il n'y a que très peu de tuto en français et présentant l'utilisation de cette solution sous linux et pas win. N'utilisant pas linux je suis un peu perdu quand ils parlent de compilation nottament...
NB: Mon serveur de developpement est sous win et mon hebergeur sous linux.
 
Merci encore

Si tu tiens absolument à utiliser xml/xslt sur ton projet, tu peux également prendre le problème dans l'autre sens.
 
Tu fais de la mise en cache de tes pages en xHTML, et pour interfacer ton site tu proposes un webservice qui sort un flux xml issu de l'application de xslt sur tes pages xHTML.

Ha ben dit donc, elle est vraiment pourri la partie de la doc sur gettext. heureusement qu'il y a les commentaire dessous pour fournir des exemples sinon ça serait impossible à utiliser. D'ailleurs même en survolant les commentaires, j'ai toujours pas pigé quel format les fichiers de traduction sont censé avoir.

Salut,
Perso j'utilise très régulièrement ETS, système de template très efficace, et pour éviter de parser systématiquement, il y a un système de cache.

Ben je voulais justement ne pas utiliser de système de cache, sinon ce serai trop beau
 
Sujet clos merci pour votre aide même si je galère avec gettext O_o