🌍
Français
nicolas a écrit:
Ce genre de code n'a absolument pas sa place dans un template. Déja utiliser isset dans un template je trouve cela pénible mais alors stripos c'est du grand n'importe quoi. Cela donne l'impression qu'il faut être développeur pour écrire des templates.
Comme je le disais dès le début, c'est exactement pour ca que je préfère la méthode du préfiltre ;-)
Vu la complexité des thèmes de WordPress et la quantité produite, je pense que cela tient d'abord du nombre potentiel d'utilisateurs et que la complexité influe mais dans une moindre mesure.
Dans le cas présent, nous parlons bien d'un montblancxl à la sauce d'un utilisateur ; donc cas particulier, et si cas particulier, alors la présence de fonction stripos dans une condition n'a rien de bien gênant.
Mais on fera mieux et également pire.
;-)
mathiasm a écrit:
C'est le problème du moteur de template: soit haut niveau et faible souplesse, soit l'inverse. Le moteur magique qui fait les deux n'est pas encore arrivé. On a choisi un peu plus de complexité pour beaucoup plus de souplesse avec Smarty. Ça convient bien aux acharnés du template que nous avons.
Je suis d'accord mais le but est d'avoir le plus de templates possibles. Je pense que le niveau technique pour réaliser un thème complet (non dérivé ou non copier/coller) est bien trop important pour que l'on voit augmenter le nombre de thèmes réellement différents les uns des autres.
nicolas a écrit:
P@t a écrit:
Code:
{if (isset($U_MODE_POSTED) and stripos($U_MODE_POSTED,'category')>0) or (isset($U_MODE_NORMAL) and stripos($U_MODE_NORMAL,'category')>0) }[/b] <div id="content" class="content"> <div class="titrePage"> ... more ...Ce genre de code n'a absolument pas sa place dans un template. Déja utiliser isset dans un template je trouve cela pénible mais alors stripos c'est du grand n'importe quoi. Cela donne l'impression qu'il faut être développeur pour écrire des templates.
Je pense qu'on a beaucoup de boulot à faire sur ce point si on veut voir fleurir les thèmes ce qui serait de saison.
Je ne sais pas ce qu'il faut modifier dans smarty et dans notre code pour écrire plus simplement :Code:
{if $U_MODE_POSTED or $U_MODE_NORMAL} ...
C'est le problème du moteur de template: soit haut niveau et faible souplesse, soit l'inverse. Le moteur magique qui fait les deux n'est pas encore arrivé. On a choisi un peu plus de complexité pour beaucoup plus de souplesse avec Smarty. Ça convient bien aux acharnés du template que nous avons.
VDigital a écrit:
tosca a écrit:
Ca pourrait aussi faire partie d'une doc développeur ...
Oui, je suis d'accord mais cela devrait changer et devenir plus cohérent dans les prochaines releases.
Et tu te donnerais un mal de chien pour rien, enfin pas pour rien mais pour une durée limitée.
Moi, non ! En l'occurrence, je me positionne en tant qu'utilisateur - et demandeur - d'une telle doc.
En l'état actuel des choses, je préfère attendre pour entreprendre quelque développement que ce soit ; quant à rédiger quoi que ce soit pour d'autres, ça me paraît nettement au-delà de mes capacités pour un bon moment encore.
*********
Je ne suis pas certain que la discution soit encore dans la bonne section du forum, voir même dans le bon forum tout court. La programmation c'est sur le forum centrale :-)
*********
tosca a écrit:
VDigital a écrit:
... $U_MODE_POSTED et pas $U_MODE_CREATED, il faut surtout comprendre ce que les champs contiennent, pourquoi et cela relève de l'expérience.
Ca pourrait aussi faire partie d'une doc développeur ...
Oui, je suis d'accord mais cela devrait changer et devenir plus cohérent dans les prochaines releases.
Et tu te donnerais un mal de chien pour rien, enfin pas pour rien mais pour une durée limitée.
(Cf. mon post précédent.)
Tu pars dans un bel [hs].
[hs]
Dans ce cas, je recommanderai volontiers des fonctions simples et claires:
{if main_index() }
Et quand tu en arrives là... Tu te demandes pourquoi tu as choisi d'utiliser Smarty et pas directement php (qui a été conçu pour parser au départ). Pourquoi? Alors que tu sais tr_s bien que quand on aura codé toutes les fonctions nécessaires, nous aurons sans doute comme beaucoup d'autres la réponse à ce pourquoi.
[/hs]
P@t a écrit:
Code:
{if (isset($U_MODE_POSTED) and stripos($U_MODE_POSTED,'category')>0) or (isset($U_MODE_NORMAL) and stripos($U_MODE_NORMAL,'category')>0) }[/b] <div id="content" class="content"> <div class="titrePage"> ... more ...
Ce genre de code n'a absolument pas sa place dans un template. Déja utiliser isset dans un template je trouve cela pénible mais alors stripos c'est du grand n'importe quoi. Cela donne l'impression qu'il faut être développeur pour écrire des templates.
Je pense qu'on a beaucoup de boulot à faire sur ce point si on veut voir fleurir les thèmes ce qui serait de saison.
Je ne sais pas ce qu'il faut modifier dans smarty et dans notre code pour écrire plus simplement :
{if $U_MODE_POSTED or $U_MODE_NORMAL}
...VDigital a écrit:
... $U_MODE_POSTED et pas $U_MODE_CREATED, il faut surtout comprendre ce que les champs contiennent, pourquoi et cela relève de l'expérience.
Ca pourrait aussi faire partie d'une doc développeur ...
P@t a écrit:
VDigital a écrit:
Je ne vois pas trop l'intérêt de doubler le test.
1 - La date "posted" existe toujours donc on devrait pouvoir disposer du calendrier.
2 - La date "created" n'est pas toujours disponible donc certains sites pourrait vouloir l'enlever.Si je clique sur "afficher un calendrier par date d'ajout", alors $U_MODE_POSTED n'existe plus.
Le second test devrait se faire plutot sur $U_MODE_NORMAL, au temps pour moi...
Si $U_MODE_NORMAL est actif, c'est que tu n'es plus sur la page d'accueil principale or il me semblait que le bloc principal #content devait ne pas s'afficher que sur l'index standard.
Je peux me planter également... ;-)
Gotcha a écrit:
L'avantage du plugin perso, c'est que l'on ne touche pas trop aux fichiers fourni et il s'agit juste d'un copié/collé, ce qui est bien plus simple pour l'utilisateur lambda que la technique du template-extension.
C'est vrai aussi, mais nous avons beaucoup d'utilisateurs qui veulent en même temps comprendre ce qu'il font et savoir le refaire seuls pour d'autres besoins si cela s'avère nécessaire.
Le plugin est parfait mais demande un niveau de confort dans le code php un peu plus conséquent que la seule partie tpl.
VDigital a écrit:
Je ne vois pas trop l'intérêt de doubler le test.
1 - La date "posted" existe toujours donc on devrait pouvoir disposer du calendrier.
2 - La date "created" n'est pas toujours disponible donc certains sites pourrait vouloir l'enlever.
Si je clique sur "afficher un calendrier par date d'ajout", alors $U_MODE_POSTED n'existe plus.
Le second test devrait se faire plutot sur $U_MODE_NORMAL, au temps pour moi...
{if (isset($U_MODE_POSTED) and stripos($U_MODE_POSTED,'category')>0)
or (isset($U_MODE_NORMAL) and stripos($U_MODE_NORMAL,'category')>0) }
<div id="content" class="content">
<div class="titrePage">
... more ...
{if !empty($PLUGIN_INDEX_CONTENT_END) }{$PLUGIN_INDEX_CONTENT_END}{/if}
</div> <!-- content -->
{/if}
VDigital a écrit:
3 - Je n'ai pas regardé si tu avais configuré leur affichage dans Piwigo 2.1.
4 - On pourrait se baser sur l'url de la page également (absence de category dans les paramètres (ce qui rendrait la solution viable en 2.1).
En effet, en 2.1, U_MODE_POSTED pourra disparaitre en quelques cliques!
Il faut trouver quelque chose de mieux...
VDigital a écrit:
5 - Je sais donc pourquoi tu préfères le préfiltre, mais je considère ce choix comme à réserver aux utilisateurs très avancés.
Je suis d'accord avec Gotcha, c'est bien plus simple de faire un copier/coller dans son plugin perso que de mettre les mains dans les templates-extensions...
@P@t
Je ne vois pas trop l'intérêt de doubler le test.
1 - La date "posted" existe toujours donc on devrait pouvoir disposer du calendrier.
2 - La date "created" n'est pas toujours disponible donc certains sites pourrait vouloir l'enlever.
3 - Je n'ai pas regardé si tu avais configuré leur affichage dans Piwigo 2.1.
4 - On pourrait se baser sur l'url de la page également (absence de category dans les paramètres (ce qui rendrait la solution viable en 2.1).
5 - Je sais donc pourquoi tu préfères le préfiltre, mais je considère ce choix comme à réserver aux utilisateurs très avancés.
@arn_bwkrd
Smarty.net propose une doc en français/anglais/... très complète et parfois plus juste que la doc de php en français.
Après pour trouver pourquoi j'utilise $U_MODE_POSTED et pas $U_MODE_CREATED, il faut surtout comprendre ce que les champs contiennent, pourquoi et cela relève de l'expérience.
Ça viendra, c'est comme le vélo, on tombe souvent au début.
L'avantage du plugin perso, c'est que l'on ne touche pas trop aux fichiers fourni et il s'agit juste d'un copié/collé, ce qui est bien plus simple pour l'utilisateur lambda que la technique du template-extension.
Mais là du coup, on a le choix :-)