Template completement séparé du code
salut,
J'utilise en local pour en vu de mon nouveau site web Pluxml beta (avec le blog)... Je l'adore tout simplement! Enfin un soft simple et efficace.
Cependant étant moi-même developpeur, je bug surtout sur un niveau : Le template. Je m'explique...
Il serait plus simple je crois de faire comme j'ai l'habitude de faire quand je fait des scripts pour clients. De cette facon, ca amplifie la compatibilité en plus a travers les versions... séparer completement le code du template. Voici les avantages:
1. Le webmaster bidouille pas dans le code directement mais uniquement dans la section template.
2. Les 'Tags' de templates, s'il sont pas utilisés (a cause par exemple d'une rétro-compatibilité) ne sont tout simplement pas utilisé et ne sont pas affiché tout simplement car non-attribués.
3. Niveau Design, les designers adore car ils se concentre que sur leur design et facilite GRANDEMENT l'intégration finale.
Par exemple, prenons les titres de site+descriptions : Ils pourrons etre tout simplement etre mises dans le template avec leurs tags respectifs soit : <p>{titre} - {soustitre}</p>.
Ce qui simplifie aussi d'ajouter aussi par exemple la partie blog au template...
Autre point : Le captcha anti-spam...
C'est une très bonne facon de faire, par contre d'ajouter un captcha graphique sera mieux (mais légèrement moins performant puisque cela prend la librarie GB). Cela pourrais etre plus clair pour les utilisateurs.
PS: Je peut aider si vous le voulez bien (niveau intégration template, programmation).
Désolé pour ce premier post... Il est tres long! Mais je suis un passionné que voulez-vous!
A+
J'utilise en local pour en vu de mon nouveau site web Pluxml beta (avec le blog)... Je l'adore tout simplement! Enfin un soft simple et efficace.
Cependant étant moi-même developpeur, je bug surtout sur un niveau : Le template. Je m'explique...
Il serait plus simple je crois de faire comme j'ai l'habitude de faire quand je fait des scripts pour clients. De cette facon, ca amplifie la compatibilité en plus a travers les versions... séparer completement le code du template. Voici les avantages:
1. Le webmaster bidouille pas dans le code directement mais uniquement dans la section template.
2. Les 'Tags' de templates, s'il sont pas utilisés (a cause par exemple d'une rétro-compatibilité) ne sont tout simplement pas utilisé et ne sont pas affiché tout simplement car non-attribués.
3. Niveau Design, les designers adore car ils se concentre que sur leur design et facilite GRANDEMENT l'intégration finale.
Par exemple, prenons les titres de site+descriptions : Ils pourrons etre tout simplement etre mises dans le template avec leurs tags respectifs soit : <p>{titre} - {soustitre}</p>.
Ce qui simplifie aussi d'ajouter aussi par exemple la partie blog au template...
Autre point : Le captcha anti-spam...
C'est une très bonne facon de faire, par contre d'ajouter un captcha graphique sera mieux (mais légèrement moins performant puisque cela prend la librarie GB). Cela pourrais etre plus clair pour les utilisateurs.
PS: Je peut aider si vous le voulez bien (niveau intégration template, programmation).
Désolé pour ce premier post... Il est tres long! Mais je suis un passionné que voulez-vous!
A+
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Ton exemple des titres de site, ... est plutôt mal chosi puisque dans pluxml, le titre du site et le sous-titre se modifient dynamiquement depuis l'admin du site.
Pour le captcha, c'est pas mon domaine, mais perso, je le trouve très bien comme ça, après il faut garder à l'esprit que c'est quelque chose que Skyline a développé dans l'urgence, très rapidement, donc peut-être a-t-il déjà prévu une évolution dans la prochaine version.
Bonne journée
template.php / style.css est effectivement réservé qu'a la template MAIS template.php contient du code php ET du output réservé a l'affichage ce qui peut être mélangeant pour les integrateur qui ne sont pas developpeur php... C'est ce que je voulais dire par 'séparer' la source html du code.
L'exemple titre/sous-titre est mal choisir pour expliqué ce que je voulais dire mais pas tant que ca... Je sais tres bien que les valeurs sont dans le config.xml, ce n'est pas le point. Il ne faut pas mélanger valeur de config avec integration html... C'est une tout autre chose!
A toute fin utile, pluxml repose que sur une page d'affichage, je ferais sans doute un exemple concret sous peu pour mieux expliqué mon point de vue (si M.Andersson permet de modifier le code de template.php intensivement). Personnellement, je connais très bien le php, donc comme il est cela ne me cause pas de probleme, je ne fait que soulever un point que mes clients aiment avoir. Cela peut servir à l'evolution de pluxml et de sa futur communauté de thèmes...
Le captcha c'est pas grave. En autant qu'il permet de filtrer le spam, c'est parfait.
Perso, il m'est arrivé de passer un Pluxml à un designer qui ne connaissait rien, mais rien au PHP, et ça a donné un super design
Deuxièmement, afficher le code PHP dans le template permet d'avoir un oeil sur ce qui va être inséré,
Troisièmement, un template ne ferait qu'alourdir Pluxml.
Enfin, les templates style PHPLIB, avec des <p>{titre} - {soustitre}</p>, je trouve ça moyen
Qu'i a-t-il de plus chiant que de devoir tout le temps laisser Alt Gr apuyé pour faire du coding ?
C'était mon avis, je ne suis pas partisant (d'autant plus que les classes PHP facilitent énormément la lecture du code), mais j'attends de voir les autres avis.
L'idée d'un vrai système de template me plait mais ça me pose quelques problèmes :
- ça demande un traitement php qui n'est pas négligeable (et Pluxml ne doit pas devenir une usine à gaz)
- ça limite celui qui veut "bidouiller" son Pluxml car il ne pourra pas ajouter directement du code php dans son template (s'il y a une solution je veux bien que l'on me l'explique)
- ça se complique dès que l'on a à faire avec des conditions ou des boucles php pour l'affichage (pareil, s'il y a une solution simple je suis preneur)
Pour le capcha, je me contente du système actuel, il est extrèmement simple et suffisemment efficace.
Je serais ravi de pouvoir parler php avec toi, un accès au forum privé de dev' t'intéresse ?
Une personne qui comme moi connait plutôt pas mal xhtml css mais plutôt pas bien php, n'aura aucune difficultés à modifier/créer un template pour pluxml tel qu'il est fait aujourd'hui, pourquoi parce qu'effectivement il faut modifier le fichier "template.php", mais pas pour faire du php sinon de l'html, et encore si c'est un template simple, le fichier template php n'a même pas besoin d'être ouvert, la css suffit, il faudra le modifier seulement si l'on souhaite rajouter des balises, en enlever ou en déplacer, mais là encore ce n'est que de l'html.
Et comme le dit Skyline, si on a envie d'aller un peu plus loin et de faire des modifs php, on peut et ça c'est quand même pas mal, car même moi qui ne suis pas un pro (n'est-ce pas Skyline
En bref, pour ne parler que de moi que je claserais moi même dans la catégorie de l'utilisateur webdesigner (celui qui est visé donc par le système de template), le système de pluxml est très bien à l'heure actuelle, c'est même le meilleur que j'ai vu jusque là, le plus simple si on le compare au système de template de "plone" ou "typo3" par exemple.
Je me permets de donner un avis sur ce thread, s'il est vrai que le système de template utilisé sur le script Pluxml manque de souplesse car mélangant le contenu avec le contenant, il va très bien dans l'esprit Pluxml qui est de rester "léger" ...
Je connais sur le bout des doigts un autre CMS en tant que webdesigner, codeur et webmaster du site freeguppy et du script GuppY, je peux t'assurer que le système actuel utilisé est loin d'être "convivial". Ce n'est pas une critique mais un fait, et ce CMS est loin d'être "une usine à gaz" . Plus vous voulez tendre à séparer deux blocs qui doivent cohabiter au final et plus vous aller au devant de complexité en terme de codification (PHP, intégration de balise CSS, sécurité ect ...)
Donc c'est un problème qui est vrai pour tout script digne de ce nom !
Je ne dirais qu'une chose (qui a déjà été dite sur ce forum). Il faut laisser le destin de Pluxml entre les mains de son concepteur et ne pas vouloir essayer de donner un point de vue différent sur le principe déjà adopté, mis en place et en test "béta" ...
Je ne sais pas si mes propos seront bien compris mais je dis que la critique est facile même si elle part d'un bon sentiment (ceci pour l'internaute qui a initié ce fil)
Merci pour cette accueil! Je ne pensais pas être aussi populaire pour un premier post! ahahah!
L'idée de templates pour certain ici est inutile, je peut le comprendre vu que surement ils font que sommes toutes des modifs mineures au script. Enfin bref, si c'est pas une bone idée pour vous c'est pas grave!
Skyline : Oui je comprend parfaitement de ne pas faire de Plux une usine a gaz, j'optimise moi-meme mes scripts avec cette optique. Je ne fesais que souligner un point que mes clients demandent. Si c'est trop de probleme, ce n'est pas grave !
Je te comprend de dire que les autres cms sont des usines a gaz... Car elle ne sont pas bien monté (généralement). L'avantage d'un systeme de template est aussi pour le createur du script... De cette facon, les modules script sont totalement indépendant du template de sortie, d'ou sa plus grande facilité de gestion quand il y a un support à faire.
Bon Plux!
J'apporte une option, elle ne semble pas etre bonne. Cela ne va pas changer ma vie. donc aucune agressions et/ou autres de ma part. peace!
"PHP est déjà un moteur de template" (je l'ai vu sur un forum, je sais plus où).
Pour moi l'essentiel est que les balises générées par les fonction sont logiques par rapport à ce qu'elles doivent sortir : listes pour les menu, paragraphe pour la pagination, etc. Ce qui est le cas dans pluxml
Après rien n'empêche l'intégrateur de rajouter une div#menu autour de la liste pour l'attteindre avec CSS.
C'est en gros une technologie qui grâce à des tempalte (les feuilles XSL) transforme des fichiers XML en autre fichier XML.
Et niveau vitesse/usine à gaz c'est niet : 0.005 seconde à transformer en XHTML, et ceci en séparant le fichier de template en plusieurs fichiers séparés qui sont importés.
De plus la technologie est entièrement basée sur XML ce qui entre parfaitement dans la logique PluXML.
Le seul problème, qui n'est pas des moindre, c'est que PHP4 gère très mal XSLT (même si il le fait je crois bien) et donc c'est peu implémentable à l'heure actuelle. Cependant ce système de tempalte standard, simple et intégré à PHP sera à mon avis à privilégier dans le futur !
Concernant le captcha je ne suis pas d'accord : je rapelle que PluXML se veut accessible ! Comment fait un aveugle ou une personne utilisant un navigateur non graphique pour lire ton image dis-moi ? Il ne peut pas.
Je dis donc non, purement et simplement, à un captcha graphique. A la limite je trouve qu'un captcha tout court est de trop, ce serait plutôt au script de chercher des "indices" qui font penser que le message est un spam et éventuellement, en cas de doute, demander une confirmation de ce type à l'utilisateur.
Voilà d'ailleur un article très intéressant àa ce sujet : http://webaim.org/blog/2007/03/07/spam_free_accessible_forms/
Tu crée un simple <input type="hidden"> sensé accueillir une adresse internet. Et tu demandes à PHP de ne pas faire de requête si ce champ est rempli (puisqu'un humain ne le voit pas quelles que soient les circonstances).
Moi j'ai dit « si il zappe le CSS » ^^ Ca arrive pour les viiiieeeeuuuxx navigateurs. On sait jamais donc on est prudent
pour en revenir a cette histoire de template ... je me considere comme debutant en php et en tant qu'amateur ce que je sais est assez peu efficace/optimisé ...
Pourtant le template de pluxml est tres facile a prendre en main , une fois la prise en main faites , il suffit de "remonter" dans le "deroulement" des script pour comprendre le fonctionnement de ce cms.
Amateur et bidouilleur je n'ai pas mis longtemps a eprouvé un interet pour ce cms qui n'est pas une usine a gaz ... enfin un truc "avec l'essentiel" , libre et surtout que je peut arriver a comprendre au niveau code avec des efforts qui ne me demande pas de prendre des notes et de lire 50 chapitres theorique sur le php pour en ressortir 3 lignes pertinentes (mode=marseillais
Du coup je bricole un peu ce cms pour la curiosité et d'autres ... et en modifiant les fonctions de base ou en ajoutant je me suis aperçu tres rapidement que l'utilisation est alors difficile pour un non avertit et les/la mise a jour devenait galere .... reedition de tout les fichiers / fonctions modifié....
alors que l'on peut en fait integré les plugins a partir du template .. un simple include ou require et hop c'est parti , voici un nouveau theme qui embarque ces plug-ins . Alors pour moi , cette option est vraiment simple , plus de probleme de mise a jour pour pluxml ou les plugins embarqué et la personne qui veut user de ces plugin , n'a qu'a selectionné le theme ou elle se trouve ou les inclure avec une ligne dans son template favori.
Decidement ce cms plait
Pour le spam , j'elimine systematiquement les post contenant des liens , car c'est ce que le spam diffuse en priorité des liens ! .... Alors si je trouve une de mes pages qui commencent a etre spammé je ne valide plus aucun post contenant un lien html ou lien en bbcode .... commenter un article ne neccessite pas forcement de donner des liens cliquables, quant au formulaire de contact , les boite ou programmes mail sont configurables pour filtré les spams . Un peu brutal comme soluce j'en convient
++ et cordialement
Moi en tant que webdesigner je prefere ce systeme meme sil a une contrepartie.
La contrepartie étant relativement peu délicate compte tenu du petit nombre de fichiers à manipuler en fait (comparé à tt ce ke j'ai du affronter ds PhpNuke lol) ...
Bref, si je veux un CMS plus complet avec une vraie séparation code/template, je peux me tourner vers d'autres outils plus performants déjà existants, plus ou moins faciles à prendre en main ... alors en effet, a koi bon changer ce qui fait l'originalité et la souplesse de la solution Pluxml ?
On en peut pas TOUT avoir dans un seul outil, au rsique de finir ... avec une usine a gaz à la PhpNuke, Joomla et Co ^^
Alors il faut trouver l'outil adapté au mieux à chaque besoin, pour cela identifier les paramètres techniques dans le cahier des charges au départ et trouver la meilleure adéquation