Est-ce une bonne pratique d'utiliser des déclinaisons de squelette selon la rubrique ? (skel-12.html et skel=32.html)
Je trouve ça en effet très pratique et assez agréable à utiliser même si ça manque de sémantique.
Mais quand on <INCLUT> un squelette, il faut chercher si il en existe une déclinaison =ID pour la rubrique courante ou -ID pour une rubrique parente.
Cette recherche nécessite donc plusieurs accés à la BDD et au disque. Est-ce que ces résultats sont mis dans en cache ? Ou sinon est-ce que ça peut être significatif et même dissuasif, c'est à dire vaut-il mieux faire des squelettes plus complexes avec des successions de boucles testant la rubrique ou le secteur par exemple ?
Pour l'instant, c'est l'alternative que j'envisage et pour laquelle j'aimerais avoir un avis.
Les variantes selon une rubrique d'un squelette ne sont désormais cherchées
*que* dans le répertoire du squelette sans variante, donc ça limite le travail.
Et de toute façon, ces recherches sont faites systématiquement,
qu'elles trouvent quelquechose ou non.
Donc autant les utiliser.
ça devrait même être plus efficace si il y a une variante (surtout =idrub)
que si il n'y en a pas puisqu'une fois la variante trouvée SPIP arrête certainement de chercher !
Par ailleurs il me semble qu'il y a un cache sur les find_in_path mais là fincalement,
ça ne doit intervenir que pour le squelette sans variante.
Justement, c'est assez dispendieux comme mécanisme :
pour chaque squelette et inclusion, on regarde si il y a id_rubrique, et si oui, on regarde si un squelete-xx existe, et sinon on prend la rubrique parente et on recommence.
C'est paradoxalement pire en performance pour ceux qui ne se servent jamais de la fonctionnalité, puisque toutes les recherches échouent, donc on remonte toute l'arbo des rubriques à chaque inclusion.
Il avait été évoqué de le sortir le mécanisme dans un plugin à disposition de ceux qui utilisent la fonctionnalité.
A minima, on pourrait y associer une configuration, désactivée par défaut sur les nouveaux sites (mais active sur les anciens issus de migration).
Ben non puisque SPIP va refaire la séquence de recherche sur ton inclure
Ce qui serait le plus performant serait de dupliquer le meme squelette sans inclusion pour chaque rubrique avec un -xx
Inutile de dire que c'est à proscrire, et que c'est à la source qu'il faut traiter cela, en désactivant la recherche de squelette -xx quand on l'utilise pas.
Ben non puisque SPIP va refaire la séquence de recherche sur ton inclure
Ah oui, bien sûr...
Ce qui serait le plus performant serait de dupliquer le meme squelette sans inclusion pour chaque rubrique avec un -xx
Inutile de dire que c'est à proscrire, et que c'est à la source qu'il faut traiter cela, en désactivant la recherche de squelette -xx quand on l'utilise pas.
Et même si l'option existe ! Je ne sais pas quel est l'impact exact
sur les performances mais il faut aussi sans doute envisager d'éviter
de faire un rubrique-xx pour une seule rubrique dans un site qui en a
beaucoup puisque dans la plupart des cas d'inclure à l'intérieur du
rubrique.html l'arbo sera parcourue.
En partie :
- le parcours recursif des rubriques est maintenu avec les fonctions d'heritage de compositions
- mais on remplace un file_exists par un acces sql pour voir si la rubrique a une composition
Disons que l'on ramène tout à SQL, et il y a un potentiel d'optimisation meilleur, mais en l'état c'est kif kif.
Le plus embêtant est qu'actuellement ceux qui utilisent composition ont une double peine ...
Un define permettrait simplement de déconnecter cela en effet,
ou alors, plus finement, un paramètre supplémentaire lors de l'appel du INCLURE,
ou un INCLURE_ELARGI dont on pourrait définir les régles d'élargissements
(=id_rub possible, -id_rub accepté, compo comprise, ...)
