Rendre toutes les fonctions de listes formatables

Pierre · octobre 2015

Encore une demande d'amélioration pour la postérité. J'apprivoise de plus en plus les fonctions comme lastArtList qui formattent les items d'une boucle et nous permet d'insérer la ou les variables aux endroits désirés. Même mon ami Rockyhorror a créé une version vignetteArtList qui rend mon plugin préféré aussi flexible que pouvait l'être lastArtList.

Cette intégration a beau me combler de bonheur, certaines autres fonctions (comme par exemple artCat, artTags et d'autres du même genre) produisent une liste pondue correctement mais en n'offrant qu'un champ "séparateur" comme flexibilité. Il me semble qu'il serait très pratique d'adopter partout la même approche que dans les fonctions formattables.

Dans certains cas, le gabarit offre par sa structure le moyen de détourner la fonction originale en trichant un peu avec le concept de séparateur, du genre:

<ul class="categories">
<li>
<?php $plxShow->artCat('</li><li>') ?>
</li>
</ul>

On voit que ce n'est pas un tour de force digne de mention mais vous voyez le principe. Un look et une méthode uniformisée du genre

<ul class="categories">
<?php $plxShow->artCat('<li>#cat</li>') ?>
</ul>

offirait la flexibilité et la simplicité d'exécution qui font la fierté de la communauté Pluxml. Mon exemple choisi est simple pour illustrer le concept, certaines autres fonctions sont parfois bien plus complexes et en tireraient un avantage encore plus évident. Aussitôt que la boucle a la possibilité de contenir plus d'une variable, l'exemple ci-haut ne fonctionne plus en déguisant le séparateur. Imaginez le formulaire de commentaire, combien ce serait facile de travailler directement dans la page d'article plutôt que dans sa propre "sous-page".

Un avis du même coup aux valeureux développeurs de plugins, plus ce principe du "formattez vous-même sur place" sera normalisé, plus la courbe d'apprentissage sera réduite pour nous les utilisateurs. Nous pourrions rêver à formatter directement les fils d'Ariane, outil de recherche, liste de résultats de recherche, et tant d'autres.

Voilà pour ma liste au Père Noël. En attendant, je me débrouille en ouvrant le moins souvent possible les fichiers "core", promis...

Stéphane · octobre 2015

Bonjour Pierre
Dans quel cas utilises-tu ce genre de code

<ul class="categories">
<li>
<?php $plxShow->artCat('</li><li>') ?>
</li>
</ul>

Pierre · octobre 2015

Dans ce cas vécu, le gabarit visuel a un très beau formattage d'une jolie boîte autour des catégories actives d'un article. Le CSS formatte l'item sous forme de UL avec des LI mais des cas de DIV avec des classes ou des id sont très fréquents aussi.

Mon exemple a beau être un véritable cas (réglé en quelques minutes, j'en conviens), il servait surtout à illustrer mon concept du "formattage au lieu de livraison" comme le font si bien les fonctions classiques comme lastArtList, lastComList, catList , etc.

Les énormités comme le formulaire de commentaires par exemple (ou les plugins populaires comme l'outil de recherche) illustrent encore mieux le gain de temps et la clarté évidente au moment du codage de la page.

Stéphane · octobre 2015

Pardon mais je n'ai toujours pas compris ce que tu cherchais à avoir comme mise en page en utilisant le code de l'exemple. Etait-ce pour avoir les catégories de l'article qui ne soit pas sous forme de liste html <ul><li> ?

Pierre · octobre 2015

L'exemple

<ul class="categories">
<li>
<?php $plxShow->artCat('</li><li>') ?>
</li>
</ul>

fournirait quelque chose comme:

Cet article peut être trouvé dans les catégories
<ul class="categories">
<li>première</li>
<li>deuxième</li>
</ul>

Mon désir est d'utiliser un jour plutôt

Cet article peut être trouvé dans les catégories
<ul class="categories">
<?php $plxShow->artCat('<li>#catDansLaListe</li>') ?>
</ul>

pour obtenir le même résultat.

Encore une fois, mon exemple est simple pour illustrer le concept qui serait un grand avantage dans des applications bien plus complexes.

Stéphane · octobre 2015

Ok je pense avoir compris, tu me diras si j'ai bon

la fonction artCat() affiche la liste sous forme de lien <a> pouvant etre séparé par un caractère, à passer en paramètre de la fonction: ex artCat(',')

toi tu souhaites afficher la liste des catégories sous forme de liste html <ul><li> ce que la fonction ne permet pas de faire proprement. Il faut la détourner avec ton astuce artCat('<li></li>')

Pierre · octobre 2015

Non, pas exactement. Ce que je souhaite pour cette fonction et autant d'autres que possible est le principe de livraison par matrice avec les variables pertinentes à la portée de la main, exactement comme lastArtList par exemple. Le contenu de chacun des champs est ainsi brut et sans aucun formattage, c'est à nous de décider si on veut que ce soit une liste UL, une suite de DIV, ou toute autre structure imaginée par les designers inventifs.

Tout comme si je dormais au gaz et que j'écrivais <?php $plxShow->lastArtList('#art_title') ?> je me réveillerais avec Mon premier titreMon deuxième titre

ça peut sembler ridicule ici mais c'est exactement ce qui est le plus flexible. C'est à nous d'insérer les LI, DIV ou je ne sais quoi qui recevra le ou les champs aux bons endroits. C'est là que je mettrais, après avoir pris un bon café, quelque chose comme

<?php $plxShow->lastArtList('<li>Ce magnifique article porte le titre de <div class="super-beau-design">#art_title</div> et son numéro id est <div class="design-plus-discret">#art_id'</div></li>'); ?>

qui me produirait une page élaborée et prête à améliorer facilement. Quand le gabarit d'exemple nous est fourni tout monté avec des mots bidon à travers du design, le tout se monte en quelques minutes avec un simple copier-coller et en remplaçant les mots bidon par les variables appropriées.

Ce n'est pas aussi facile avec artCat() parce que la fonction recrache une liste de liens plutôt que de tout séparer (nom de la cat et son url) comme le fait lastArtList. Puisqu'on séparerait le tout on verrait peut-être même

L'article peut être retrouvé dans: <?php $plxShow->artCat('<div class="belle-boite"><a href="#cat_url">#cat_title</a></div>'); ?>

Tu vois le genre, une matrice avec des données "nues" fournies item par item mais c'est nous qui décidons de "l'habillage". Ça fonctionne à merveille avec lastArtList en poussant la matrice article par article, c'est le même principe.

Pierre · décembre 2015

Plus j'intègre des thèmes dans PluXml, plus mon idée se précise dans ma demande d'avoir toujours un "$format=" dans les paramètres des fonctions, quitte à en avoir un par défaut pour fins de compatibilité antérieure. Ainsi, presque tout le HTML serait retiré des fonctions à l'exception de cette clause grand-père. On voit des contraintes au niveau des commentaires, des affichages des titres, les listes clé-en-main comme artCat, etc.

Pour ces exemples, toutes sortes de paramètres sont possibles, des DIV au lieu des LI (de UL), des niveaux de titrage, etc. Cette méthode permettrait de construire un thème complet et l'offrir dans Ressources avec zéro paramétrage. On peut rêver et penser que les fonctions classiques les plus communes comme la recherche et la page contact ferait partie du lot. Ai-je passé tout le message sans parler de Vignette? ah merde... on était si près.

bazooka07 · décembre 2015

Bonjour,

Tu veux un like ?
Comme toi, je pense qu'il faudrait généraliser le $format pour avoir plus de possibilités d'affichage.
Il faudrait par exemple ajouter à $plxShow une fonction qui permettrait de préciser dans une chaine de format les champs de l'article à afficher comme on le fait pour la fonction lastArtList. On pourrait ainsi afficher des champs supplémentaires.
Je vais rajouter un hook au plugin chamPlus pour cela très bientôt, qui fait plus que d'afficher des vignettes.

A++

Pierre · décembre 2015

Tant mieux si je ne suis pas complètement fou! La flexibilité des fonctions avec le $format est clairement démontrée, on devrait pouvoir convaincre facilement de les intégrer partout.

Et puisqu'on y est, je transformerais tous les ECHO dans les fonctions par des RETURN, ce qui nous permettrait "d'utiliser" les données retournées plutôt que de forcément les afficher. Au moment de bâtir la page, il nous faudrait simplement écrire le ECHO $plxShow... si aucune opération n'était nécessaire. Mais là, j'en espère peut-être un peu trop, c'est ma nature...

bazooka07 · décembre 2015

Bonjour,

J'ajouterai que pour ajouter des champs aux articles, c'est le grand Barnum. Mais on y arrive.

Les rafales de "echo" me font mal aux yeux aussi. L'utilisation du heredoc rend les choses plus lisibles pourtant.

La fonction première d'une fonction de $plxShow est d'afficher quelque chose à l'écran. Donc l'usage à l'intérieur d'un "echo" me semble normal. Par contre, l'usage d'une chaine de format en tant que paramètre devrait se développer.

Une autre idée qui me trotte dans la tête est de remplacer cet antique format xml par du json. Apparament cela bouge dans ce sens chez Wordpress.
La lecture d'un fichier json se fait en une ligne, à comparer à ce qui se fait pour le xml. Et les fichiers de données sont beaucoup plus poids plume.

A++

Pierre · décembre 2015

Côté sémantique, c'est certain que d'appeler une classe $plxShow et ne rien lui faire écrire, ça peut sembler contre nature! Alors je vote pour ouvrir une autre classe presque identique qui s'appellerait $plxGet... À mes débuts dans la famille, j'avais fait exactement ça pour extraire des articles et les traiter "à la main" et d'afficher ce que je voulais. J'apprivoise maintenant les fonctions et je n'ai plus à le faire mais la tentation est forte.

Pour JSON, je frissonne de frayeur, mes cheveux gris me trahissent, je porte le XML dans mon coeur et rebute le JSON sans grande raison à offrir. Je prend aussi un temps fou à me décider de jeter mes vieilles chaussettes bien chaudes mais trouées...

bazooka07 · décembre 2015

Bonjour,

XML est une antiquité pour moi. On utilise plus de caractères à écrire les balises que pour écrire les données. De plus le transfert d'un tableau associatif vers un fichier XML et inversement utilise beaucoup trop de lignes de codes (voir PlxMotor)
En regroupant les différents fichiers de config en un seul, on pourra charger la config de Pluxml en une ligne de code.

Le seul intérêt de XML est Xpath. J'ai toujours peiné pour trouver une doc clair et cela n'a pas d'intérêt pour Pluxml.

A++

Pierre · décembre 2015

On verra bien si la modernité l'emportera sur la valeur sûre du passé qui prend de l'âge un peu. Un autre de mes arguments vient du fait que je dois parfois initier des clients à la manipulation de données. Ces personnes, déjà effrayées à l'idée d'avoir à toucher du code, acceptent souvent assez bien le concept XML pour sa clarté, surtout quand on ajoute une troisième dimension.

[== XML ==]
<?xml version="1.0" encoding="ISO-8859-1"?>
<document>
<patient>
<firstname>Test</firstname>
<lastname>Patient</lastname>
</patient>
<allergies>
<allergy>
<name>Wheat</name>
<severity>3</severity>
</allergy>
</allergies>
</document>

Je n'ai pas le choix d'avouer que c'est une énorme quantité de caractères pour très peu de véritables données mais j'aime bien la représentation canonique qui se saisit assez bien pour un néophyte.

Avec JSON, c'est le triomphe de l'efficacité. On pourrait argumenter que la clarté est un concept bien personnel et que chacun a son niveau de confort mais j'enseigne souvent les rudiments de XML juste après avoir initié la même personne au HTML. Leur ressemblance étant flagrante, la courbe d'apprentissage devient moins intimidante, un argument important pour gagner de la confiance.

Une nouvelle exception dans le débat, j'ai côtoyé des étudiants en design web qui faisaient évidemment du CSS dans leur sommeil. Tu me vois venir, ils ont compris en quelques secondes leur première feuille de code JSON, tellement la structure leur était familière. Mais mon argument tient toujours, ces personnes sont, techniquement, des informaticiens, je fais affaire surtout avec des gens qui s'intimident facilement et abandonnent à la moindre embûche. J'aimerais bien les voir coder en Assembler...

Scith · décembre 2015

Salut,
Je suis d'accord dans l'idée même si j'ai pas tout lu (désolé Pierre mais je trouve tes messages souvent un peu longs

)
Soit pouvoir personnaliser le format de toutes les fonctions comme suggérées, soit proposer de retourner un array de données (ce qui serait bien plus flexible).
Dans l'idée : <li><a href="'.$art[link].'">'.$art[title].'</a></li>

J'ai moi même des soucis avec la customisation d'artCat et artTag notamment.
Je trouve qu'il manque parfois de cohérence dans les fonctions : certaines crachent du HTML quand d'autres sortent des données avec format perso, certaines ont des séparateurs d'autres non, etc ... A mon avis toutes les fonctions devraient sortir des données (GET) en Array et le reste est à la charge de la page PHP (formatter, faire des boucles sur les articles, etc ...)

En fait il faudrait faire un peu comme le format des requêtes SQL selon moi ... Ca n'empêche pas d'avoir à côté des fonctions de formattage qui crachent du HTML pour faciliter la tâche aux codeurs occasionnels mais je ne pense pas que ça devrait être la norme

Pierre · décembre 2015

Ah, ces jeunes... on ne veut plus lire de nos jours.

Parler, c'est la liberté. La passion, ça ne se livre pas en 140 caractères...

Scith · décembre 2015

Je suis bien d'accord

Mais pour le coup le titre du topic est très clair et se suffit à lui-même : toutes les fonctions ne sont pas formattables ce qui est un problème évident à résoudre.

bazooka07 · décembre 2015

@Scith,

artTags() accepte une chaine de format en paramètre. Par défaut la chaine est comme ceci

[== PHP ==]
artTags($format='<a class="#tag_status" href="#tag_url" title="#tag_name">#tag_name</a>', $separator=',')

artCat() n'accepte pas de chaine de format. C'est vrai qu'on peut en avoir besoin parfois. Mais c'est facilement modifiable.
Pour les autres champs des articles, c'est vrai qu'il n'y a pas de fonction. J'ai rajouté un hook au plugin chamPlus pour pallier à ce manque. Mais cela est plus compliqué à coder que dans les 2 cas précédents. Le hook est récent. J'attends des retours pour éventuellement appliquer des correctifs.

Maintenant si tu veux travailler à un niveau plus bas, tu peux t'inspirer du template ci-dessous à appliquer à une catégorie, ou dès qu'il s'agit d'afficher un ou plusieurs articles.
template categorie-raw.php à ajouter au thème utilisé

[== PHP ==]
<?php include(dirname(__FILE__).'/header.php'); ?>
	<main>
		<section id="categorie">
			<nav id="pagination"><?php $plxShow->pagination(); ?></nav>
			<p><?php $plxShow->lang('CATEGORIES'); echo ':&nbsp;'; $plxShow->catName(); $plxShow->catDescription(' : #cat_description'); ?></p>
<?php while($plxShow->plxMotor->plxRecord_arts->loop()) { ?>
			<article id="post-<?php echo $plxShow->artId(); ?>">
				<pre><code>
<?php
	$i = $plxShow->plxMotor->plxRecord_arts->i;
	$article = $plxShow->plxMotor->plxRecord_arts->result[$i];
	print_r($article);
?>
				</code></pre>
			</article>
<?php } ?>
			<?php $plxShow->artFeed('rss', $plxShow->catId()); ?>
		</section>
<?php include(dirname(__FILE__).'/sidebar.php'); ?>
	</main>
<?php include(dirname(__FILE__).'/footer.php'); ?>

Le résultat est visible ici : http://www.jeveuxpartir.net/pluxml/index.php?categorie5/livre-xii

Mais pas sûr que beaucoup de gens accrochent.

A++

Pierre · décembre 2015

Une bonne piste est la façon dont Rockyhorror a offert deux méthodes de livrer à l'écran la fonction Vignette, dont une version révisée de lastArtList. Je sais que vignetteArtList ne fait pas l'unanimité mais j'aime bien que l'on puisse l'utiliser en ne poussant que la fonction, ou alors en incluant une matrice (array) pour y ajouter des paramètres. C'est peut-être une option à explorer.

danielsan · décembre 2015

hello,
j'émets un énorme +1 pour le formatage des listes pour plus de souplesse dans l'affichage des données
et de rajouter des variables "brutes" comme

[== PHP ==]
$t = plxUtils::title2url($tag);
$name = str_replace('#tag_item',$t,$format);

pour ajouter des class "uniques" par exemple

je fais ces modifs car j'utilise jqueryMobile, associe des icônes aux éléments

danielsan · décembre 2015

un petit mot pour le XML vs Json : la portabilité du XML.
Il m'arrive d'interroger le dossier data à partir d'un logiciel tierce voir de créer un fichier XML qui sera lu par PluXml ... c'est ce qui fait que j'ai choisi PluXml.

Pierre · mars 2016

Un nouvel exemple de l'incongruité des formats entre les fonctions et une illustration de l'avantage d'ajouter un formatage manuel pour toutes les fonctions.

Je travaillais avec le nombre de commentaires attribués à un article dans un affichage dynamique. En lisant la documentation, j'étais très heureux de voir que la fonction artNbCom() permettait une certaine forme de formatage pour l'adapter au besoin. J'ai donc utilisé le format artNbCom('#nb','#nb','#nb') puisque je ne voulais que le chiffre, peu importe qu'il soit 0, 1 ou 99.

Je confesse que je n'ai pas étudié la page HTML rendue avant quelques essais mais la page affichée foutait tout en l'air, je cherchais ailleurs en pensant que ma lecture du manuel était bonne. Eh bien non, on a beau écrire

artNbCom('#nb','#nb','#nb')

ce qu'on imagine nous repousser un chiffre mais ce qui sort pour vrai c'est

<a href="http://un-url-que-je-ne-veux-pas/index.php?article3/mon-article#comments"; title="0 Aucun commentaire">0</a>

alors qu'on attendait 0, un point c'est tout.

On peut travailler à faire des pirouettes pour s'en sortir mais un format de fonction sert à contrôler ce qui sort, c'est génialement bien utilisé pour plusieurs fonctions de PluXml. La plus populaire sans doute, lastArtList(), est la grande championne de cette flexibilité. Même s'il lui manque encore quelques petits items comme la date morcelée, au moins elle n'ajoute pas des paramètres fantôme au milieu du formatage comme mon exemple ci-haut. Ce sera pour une prochaine version, c'est certain, mais en y allant doucement, on peut même rendre toutes les fonctions compatibles aux versions antérieurs en pré-formattant par défaut "l'ancienne" sortie HTML de chacune des fonctions retouchées.

Alors, nous l'adorons notre PluXml, pourquoi pas le rendre encore plus adorable.

Stéphane · mars 2016

Salut

artNbCom est faite pour afficher le nombre de commentaires sous forme de liens à partir de la page d'accueil ou sous forme de texte à partir de la page de l'article.

si tu veux juste afficher le nombre d'article:

<?php echo intval($plxMotor->plxRecord_arts->f('nb_com')) ?>

rien de plus

Pierre · mars 2016

Il y a souvent un moyen détourné, comme celui-ci, mais imagine avoir à faire une telle sous-extraction pour chacun des items qui existent. C'est ce que j'entend par un formatage pour toutes les fonctions.

Rien de mal à avoir une version par défaut, tu peux y mettre la version la plus "plausible" ou comme dans mon message précédent la version "backward-compatible" pour ne pas faire flancher toutes les installations de nos amis. Mon point est que la flexibilité totale est une garantie contre les imprévus. Je concède que ça ajoute des lignes dans les pages de fonctions, surtout quand on s'attaque à toutes les fonctions d'un coup comme je le suggère, mais les constructeurs de thèmes (et les "convertisseurs" comme moi) t'en seront éternellement reconnaissants.

On verra si l'avenir te donne assez de temps libre pour accomoder les grincheux, le grincheux en chef t'en remercie déjà.

Pierre · mars 2016

En voici un autre très semblable, la fonction artCat() lance elle aussi sa liste sous forme de chaîne de liens URL. Le formatage offert nous demande le séparateur mais on pousse tout de même la balise <a href... >

On peut bâtir la fonction avec ou sans la balise quand on part d'une banque de variables, disons que j'en invente une du genre

artCatList('<a href="#catUrl">#catName<a>, ')

pour reproduire la version par défaut de artCat(', ') pour quelqu'un qui veut des virgules. C'est plus facile à dire qu'à faire, surtout quand pas la même personne qui doit le faire! Ces choses-là prennent du temps, c'est la longue route vers la perfection. En attendant, merci pour les méthodes détournées pour arriver à mes fins et me la fermer!

Pierre · avril 2016

Dans ma croisade incessante pour rendre toutes les fonctions de PluXml formatables et non-affichées par la fonction elle-même, je me bute à un petit test que nos experts pourront possiblement me fournir.

J'utilise à toutes les sauces la fonction artThumbnail() mais je ne trouve pas le moyen de tester la "présence" d'un contenu dans la variable de l'url. Ceci me permettrait de faire autre chose que générer une image brisée. Je force (sans la moindre retenue ou politesse) les utilisateurs de mes thèmes à inclure une image d'accroche mais j'aimerais bien avoir l'option de faire quelque chose de plus diplomatique.

Le problème se pose doublement quand j'utilise #img_url à l'intérieur de la sacrosainte lastArtList(), là j'y vais peut-être un peu fort mais on sait jamais, elle est sacrosainte après tout...

En passant, la fameuse "option en cas d'absence" ouvre la possibilité de plusieurs comportements, pas toujours le même, je ne veux pas mettre une image bidon du type mon-webmestre-ne-veut-pas-travailler.img comme remplacement. On peut sauter l'article, piger dans une banque, piger dans son body d'article, etc.

Bref, encore une fois, parce qu'on ne peut pas lancer les fonctions d'extraction sans les voir tout nous balancer à la figure, il faut un moyen détourné. Ce serait si facile dans mon petit univers rempli de licornes et de bonbons aux cerises:

$array = lastArtList(); rien ne s'affiche

echo lastArtlist(); comportement d'aujourd'hui

Pierre · mai 2016

Je suis le seul à tenir les braises mais tant pis.

Un autre dossier sur la pile des fonctions qui ne peuvent être mises en forme sans bousiller le core alors que c'est clairement propre au thème: la pagination dans les bas de page. Elle a plusieurs visages possibles mais comportent une liste d'éléments prévisibles.

En mettant le formatage des variables dans un $fomrat, ça offrirait la flexibilité de monter la feuille de style avec ces items aux bons endroits.

Pierre · juillet 2016

En attendant l'arrivée d'une rubrique pour les suggestions à faire pour une version prochaine de PluXml, je relance mon point sur les variables de fonctions et le souhait de voir un réel clivage entre le $format et les bouts de code insérés ici et là dans les fonctions du core.

Nous avons parlé de la fonction artTags un peu plus haut mais je reviens cette fois-ci avec $plxShow->tagList qui m'a forcé à extraire la fonction au complet pour l'inclure (deux fois) dans un thème. La variable coupable cette fois-ci est #tag_size. Si la valeur était restée numérique (ce qu'elle est après tout), j'aurais pu l'insérer un peu comme ceci:

$plxShow->tagList('<a href="#tag_url" class="tag-link" title="1 topic" style="font-size: #tag_size pt;">#tag_name</a>');

eh ben non... la variable ne recrache pas un chiffre comme un simple 5, elle recrache une chaîne "tag-size-5". Cette décoration extra-numérique me force à inclure

[== Indéfini ==]
					<?php $format='<a href="#tag_url" title="#tag_name" style="font-size: #tag_sizeem;">#tag_name</a>';
						$max=''; 
						$order='';
						$datetime = date('YmdHi');
						$array=array();
						$alphasort=array();
						$plxMotor = plxMotor::getInstance();
						$plxPlugin = $plxMotor->plxPlugins->callHook('plxShowTagList');
						if($plxShow->plxMotor->aTags) {
							foreach($plxShow->plxMotor->aTags as $idart => $tag) {
								if(isset($plxShow->plxMotor->activeArts[$idart]) AND $tag['date']<=$datetime AND $tag['active']) {
									if($tags = array_map('trim', explode(',', $tag['tags']))) {
										foreach($tags as $tag) {
											if($tag!='') {
												$t = plxUtils::title2url($tag);
												if(!isset($array['_'.$tag])) {
													$array['_'.$tag]=array('name'=>$tag,'url'=>$t,'count'=>1);
												}
												else
													$array['_'.$tag]['count']++;
												if(!in_array($t, $alphasort))
													$alphasort[] = $t; # pour le tri alpha
											}
										}
									}
								}
							}
							if($max!='') $array=array_slice($array, 0, intval($max), true);
							switch($order) {
								case 'alpha':
									if($alphasort) array_multisort($alphasort, SORT_ASC, $array);
									break;
								case 'random':
									$arr_elem = array();
									$keys = array_keys($array);
									shuffle($keys);
									foreach ($keys as $key) {
										$arr_elem[$key] = $array[$key];
									}
									$array = $arr_elem;
									break;
							}
						}
						$size=0;
						foreach($array as $tagname => $tag) {
							$name = str_replace('#tag_id','tag-'.$size++,$format);
							$name = str_replace('#tag_size',($tag['count']>10?'max':(0.5+$tag['count']/5)),$name);
							$name = str_replace('#tag_count',$tag['count'],$name);
							$name = str_replace('#tag_item',$tag['url'],$name);
							$name = str_replace('#tag_url',$plxShow->plxMotor->urlRewrite('?tag/'.$tag['url']),$name);
							$name = str_replace('#tag_name',plxUtils::strCheck($tag['name']),$name);
							$name = str_replace('#nb_art',$tag['count'],$name);
							$name = str_replace('#tag_status',(($plxShow->plxMotor->mode=='tags' AND $plxShow->plxMotor->cible==$tag['url'])?'active':'noactive'), $name);
							echo $name.' ';
						}	?>

pour faire la même chose...

Pour une prochaine version, le simple fait de réellement séparer la valeur numérique pourrait remplacer la ligne

<?php $plxShow->tagList('<li class="tag #tag_size"><a class="#tag_status" href="#tag_url" title="#tag_name">#tag_name</a></li>'); ?>

par

<?php $plxShow->tagList('<li class="tag tag-size-#tag_size"><a class="#tag_status" href="#tag_url" title="#tag_name">#tag_name</a></li>'); ?>

pour respecter le thème par défaut et sa feuille de style. La différence est presque difficile à trouver.

En adoptant la bonne pratique de séparer les variables de leur formatage, personne n'en souffre, personne ne perd plus de temps, ce qui est loin d'être le cas en n'adoptant pas ce principe. Les situations comme celle décrite ici impliquent d'inclure des centaines de lignes de plus à un thème juste pour contourner les problèmes, ça fait peur au nouveaux en donnant l'impression que c'est compliqué de travailler avec PluXml. C'est bien triste.

Rendre toutes les fonctions de listes formatables

Réponses