Pertinence des recherches sur tags multiples (r547)¶
Lorsque plusieurs tags sont spécifiés en critère de recherche, ceux-ci peuvent être traités avec les opérateurs 'et' ou 'ou'. Dans le premier cas, seuls les objets comptant autant de relations que de tags sont retournés. Dans le second la recherche est plus large, mais une notion de pertinence doit alors faire son apparition.
Pour cette raison, les recherches larges sur plusieurs tags sont à présent classées par défaut selon leur nombre de relations. Par contre, si les résultats les plus pertinents sortent en premier, il faut noter que cet ordre imposé passe avant tout autre choix de tri. De ce fait ce type de recherches n'est pas adapté à un affichage des résultats dans un tableau paginé triable (il vaut mieux désactiver le tri par colonnes).
Liste des tags proches et objets similaires (r548, r551)¶
Des recherches de proximités (related)ont été ajoutées. Il s'agit avant tout de récupérer la liste des tags qui sont fréquement associés avec une liste de tags donnée. Ceci permet généralement d'étendre les recherches en suggérant des tags selon un contexte de recherche initial.
Concernant les objets similaires, ce sont ceux ayant un maximum de tags en commun avec un objet donné. Cela correspond donc à la fonction première des tags (recherche d'objet correspondant à une liste de tags). A noter qu'une méthode générique n'est pas disponible directement pour cette tâche, puisque cela implique à la fois les behaviors "taggable" et "filters".
Restriction sur les modèles (r548, r550)¶
Les recherches par tags peuvent spécifiées un modèle (classe d'objet) pour restreindre les résultats. Ceci est utilisé en particulier sur les formulaires de filtres disposant d'une autocomplétion pour ajouter des tags : puisqu'il est sans intérêt d'ajouter un critère avec un tag non utilisé parmis les objets recherchés, autant restreindre la recherche du widget d'autocomplétion pour ne retourner que des tags pertinents.
Par contre au sujet des tags proches décrits précédement, cette restriction est particulière. Vu la complexité de la requête SQL employée, si on ajoute un modèle pour restreindre les résultats à des tags proches ET utilisés avec le modèle donné, cette restriction impacte également le comptage des relations entre les tags : il y a alors perte de la notion de proximité entre tags sur les autres modèles.
Par ex si les tags 'titi' et 'toto' sont fréquement associés sur des bookmark, mais que vous recherchez les tags proches de 'toto' pour des resources, 'titi' ne comptera pas. Cela me semblait logique, mais on pourrait vouloir bénéficier des notions de proximités entre tags quelques soient les objets, tout en souhaitant en résultat éliminer les tags inutilisés sur un modèle précis. Cela n'est pas possible, il faudra donc faire un choix.
Amélioration des fonctions du helper (r554, r556)¶
Tout d'abord une évolution générale sur les fonctions du tagsHelper concernant la route indiquée pour la génération des liens :
- A défaut d'être une URI symfony valide (du type "module/action" ou "@rule" ou "http://..."), il est possible de donner du code javascript en le préfixant d'un '='. Dans ce cas la fonction link_to_function sera utilisée à la place de link_to.
- La route étant indiquée sous la forme d'un motif sprintf, elle peut désormais utilisé un second paramètre correspondant au libellé du tag en plus de la clé du tag.
Enfin une nouvelle fonction tag_select fait sont apparition : elle est similaire en tout point à tag_cloud (affichage d'une liste de tags en "nuage") en ajoutant un second lien. Chacun des tags est ainsi suivi d'une picto (par défuat [+]) disposant de ce lien alternatif. Le choix de la picto peut être spécifié en fournissant array($route, $picto) au lieu de $route.