Feat/newtextsearch2

[J9rem]

Cette pull-request a pour objectif d'améliorer le fonctionnement de l'action {{newtextsearch}} en s'inspirant de ce qui a été fait sur un wiki existant de Villeurbanne

Ceci est d'abord une pull-request draft, qui propose les améliorations en se basant sur des développements custom. Ne pas prendre le code proposé comme valide pour fusion tant que les spécifications ne sont pas validées. le code est d'abord proposé comme base de travail des spécifications qui peuvent invalider tout ou partie des modifications courantes.

Proposition de spécifications:

Spécification pour amélioration de l'action {{newtextsearch}}

• [R01] : l'action {{newtextsearch}} DOIT être réécrite dans le nouveau format dans le fichier NewTextSearchAction.php
• [R02] : le fichier docs/actions/advanced-actions.yaml DOIT être à jour par rapport aux modifications apportées concernant {{newtextsearch}}
• [R03] : l'action {{newtextsearch}} DOIT maintenant proposé un template twig par défaut newtextsearch.twig qui affiche les résultats comme avant
• [R04] : un nouveau template newtextsearch-by-form.twig devrait aussi être créé
• [R04.1] : le nouveau template de [R04] DOIT permettre l'affichage des résultats classés par formulaires ou types de données
• [R04.2] : le nouveau template de [R04] DEVRAIT afficher les données en colonnes.
• [R04.2] : le nouveau template de [R04] DEVRAIT utiliser le nouveau paramètre nbcols pour déterminer le nombre de colonnes
• [R04.3] : le nombre de colonnes du nouveau template de [R04] DOIT être entre 1 et 3
• [R04.4] : si le parmaètre nbcols vaut 0 pour le nouveau template de [R04], alors la mise en colonne DEVRAIT se faire automatiquement en fonction de la largeur du contenu
• [R04.5] : le nouveau template de [R04] DEVRAIT affiché les résultats classés par catégories
• [R04.6] : le nouveau template de [R04] NE DOIT PAS être le template par défaut
• [R04.7] : le nouveau template de [R04] DEVRAIT créer autant de lignes que nécessaire pour respecter le nombre de colonnes demandées
• [R04.8] : le nouveau template de [R04] PEUT être un affichage dynamique
• [R05] : le paramètre displaytype DEVRAIT être utilisé par les deux templates pour déterminer le type d'affichage selon:
  • modal : fenêtre modale
  • link : fenêtre courante
  • newtab : nouvel onglet
• [R05.1] : la valeur par défaut de displaytype DEVRAIT être modal
• [R06] : le paramètre displaytext DEVRAIT être utilisé uniquement par le deux templates pour déterminer s'il faut afficher le texte des résultats
• [R06.1] : les valeurs de displaytext PEUVENT être:
  • true pour forcer l'affichage du texte
  • false pour ne pas afficher le texte
  • "" pour n'afficher le texte que pour le template par défaut (c'est la valeur par défaut)
• [R06.2] : displaytext NE DEVRAIT être configurable qu'avec les paramètres avancés de composants
• [R07] : le paramètre displaytypes DEVRAIT être utilisé par le nouveau template de [R04] pour déterminer ce qu'il faut afficher et dans quel ordre
• [R07.1] : si le paramètre displaytypes est vide, le nouveau template de [R04] DEVRAIT afficher les résultats classés par formulaire pour les fiches, par ordre croissant de nom de formulaire suivi d'un bloc avec les pages sans les pages de logs
• [R07.2] : le paramètre displaytypes PEUT accepter les syntaxes suivantes, séparées par des virgules
  • un nombre : pour un formulaire spécifiques
  • page ou pages : pour les pages sans les pages de logs
  • logpage, logpages, logspage, logspages : pour les pages de logs
  • tag:<nom-du-tag> (ex: tag:catégorie: 1 pour le tag catégorie: 1)
• [R07.3] : si un résultat appartient à la fois à un tag et à la fois à un bloc page, logpage ou formId (un formulaire), ce résultat PEUT être afficher en doublon dans les deux catégories
• [R07.4] : le paramètre displaytypes DEVRAIT pouvoir être saisi facilement depuis les composants (en développant un Input dédié si nécessaire)
• [R08] : le paramètre titles DEVRAIT être utilisé par le nouveau template de [R04] pour déterminer le titre de chaque bloc
• [R08.1] : la syntaxe du paramètre titles DEVRAIT être une concaténation de texte, chaque titre étant séparés par des virgules, classés dans le même ordre que le paramètre displaytypes
• [R08.2] : si un titre est vide (ex: 1.Titre non vide 1,,3.Titre non vide 2), celui-ci DEVRAIT être remplacé par :
  • le label du formulaire pour les formulaires
  • Pages pour les pages (+ traductions)
  • Log pages pour les pages de logs (+ traductions)
  • Nom du tag pour les tags
• [R09] : le paramètre limit DEVRAIT être utilisé par le template d'origine pour limiter le nombre total de résultats fournis
• [R09.3] : le paramètre limit DEVRAIT avoir pour valeur par défaut 10
• [R09.4] : le paramètre limit DEVRAIT automatiquement être remplacer par sa valeur par défaut si sa valeur initiale est inférieure ou égal à 0
• [R09.6] : le paramètre limit DEVRAIT automatiquement être remplacer par sa valeur par défaut si sa valeur initiale est inférieure strictement à 0
• [R09.7] : le paramètre limit DEVRAIT uniquement être utilisé par le nouveau template de [R04] pour déterminer le nombre maximum de résultats par catérgorie
• [R10] : le nouveau template de [R04] DEVRAIT proposer un bouton voir plus quand la limite est atteinte par limit
• [R10.2] : le bouton voir plus NE DEVRAIT PAS recharger la page pour n'afficher que les résultats de la catégorie concernée sans limite
• [R10.3] : le bouton voir plus DEVRAIT mettre à jour la liste des résultats concernant la catégorie de façon dynamique
• [R11] : le clic sur un résultat PEUT ouvrir la page avec une ancre au bon endroit
• [R11.3] : les actions show__ et iframe__ DEVRAIT prendre en compte $_GET['searchAnchor'] afin d'ajouter à la volée une ancre pour faciliter la navigation

Changements

• 2022-08-31 [JD]:
  • [R04.6] ~~DEVRAIT~~ => NE DOIT PAS
  • [R04.7][R04.8] ajout
  • [R09] ~~tous les templates~~ => le template d'origine
  • [R09.1] suppression : ~~le paramètre nbbytypes DEVRAIT uniquement être utilisé par le nouveau template de [R04] pour déterminer le nombre maximum de résultats par catérgorie~~
• [R09.2] suppression : ~~le paramètre limit DEVRAIT être prioritaire sur le paramètre nbbytypes~~
• [R09.3] ajout de par défaut 100 pour le template d'origine est 10 pour le nouveau template
• [R09.5] suprresionn ~~: le paramètre nbbytypes DEVRAIT avoir pour valeur par défaut 0, ce qui correspond pas de limite~~
• [R09.7] : ajout
• [R10] : nbbytypes => limit
• [R10.1] suppression : ~~le bouton voir plus DEVRAIT recharger la page pour n'afficher que les résultats de la catégorie concernée mais sans limite de nbbytypes (en gardant la limite de limit)~~
• [R10.2][R10.3]: ajout
• [R11.1] suppression : ~~un handler avec le nom /anchor PEUT être créé afin d'ajouter à la volée une ancre pour faciliter la navigation~~
• [R11.2] suppression : ~~un handler /anchoriframe PEUT être aussi créé pour le contexte iframe~~
• 2022-09-07 [JD]:
  • [R07.2] : suppression de
    • ~~tagonpage:<nom-du-tag> (ex: tagonpage:catégorie: 1 pour le tag catégorie: 1 concernant que les pages)~~
    • ~~tagonforms:<nom-du-tag> (ex: tagonforms:catégorie: 3 pour le tag catégorie: 3 concernant que les fiches)~~
    • ~~tagonformXX,XX:<nom-du-tag> (ex: tagonform1,33:catégorie: 3 pour le tag catégorie: 3 concernant que les fiches des formulaires 1 et 33)~~
    • [R09.3] : valeur par défaut 10 (au lieu de différencier pour chaque template)
    • [R11.3] : ~~$_GET['search_anchor']~~ => $_GET['searchAnchor']

---

Ce que fait la branche en l'état

• refactor de {{newtextsearch}}
• création d'un nouveau template avec affichage par colonne des résultats groupés par formulaire
• ajout des paramètres existant dans advanced-actions.yaml
• ajout des nouveaux paramètres liés au nouveau template
• l'affichage est maintenant dynamic

Pour tester la branche en l'état

• dans une page, utilisez le bouton composants > Actions avancées > Recherche de texte pour ajouter l'action {{newtextsearch}}
• régler à votre convenance les nouveaux paramètres
• faire une recherche et apprécier

[J9rem]

@mrflos @EdmondAgate je viens de mettre à jour le commentaire de tête avec les spécifications que je propose pour l'amélioration de newtextsearch Qu'en dites-vous ?

[mrflos]

Hello, je vais passer mon tour sur ces specs, je suis personnellement pas très enthousiaste sur cette fonctionnalité, je ne trouve pas l'affichage par colonne pertinent dans une recherche globale (ca fait souvent des colonnes vides), et je trouve que cela fait très bric à brac d'option et mouton à cinq pattes.
Je ne voies pas non plus ou implémenter cette fonction dans le wiki de base, de pouvoir discriminer les formulaires n'a pas de sens dans la recherche globale, et de la faire ailleurs, je préférerais le faire avec bazarliste qui offre plus de personnalisation avec les facettes, les queries, et les templates (le seul avantage serait de pouvoir afficher des pages avec des fiches, mais c'est tout). Ca a aussi le désavantage de ne pas etre dynamique: je fixe sur les 3 formulaires que j'ai créé la recherche, si jamais je rajoute des formulaires, je vais devoir penser à changer les actions de recherche pour les intégrer. Aussi, je trouve la syntaxe des options un peu trop geek et pas très parlante.

Bref, si les gens de la communauté yeswiki y voient un intérêt, je ne vais pas faire mon pénible, mais personnellement, je ne trouve pas que cela va dans la bonne direction, désolé..

[J9rem]

@mrflos

(le seul avantage serait de pouvoir afficher des pages avec des fiches, mais c'est tout).

c'est justement l'avantage qui est recherché

je fixe sur les 3 formulaires que j'ai créé la recherche, si jamais je rajoute des formulaires, je vais devoir penser à changer les actions de recherche pour les intégrer.

pas vraiment, car c'est un affichage flexbox donc les nouveaux formulaires s'affichent en dessous

L'intérêt est aussi d'éviter que la recherche globale scanne certains formulaires où les informations ne sont pas toujours valides pour être mises en avant dans la recherche globale.

Bref, si les gens de la communauté yeswiki y voient un intérêt, je ne vais pas faire mon pénible, mais personnellement, je ne trouve pas que cela va dans la bonne direction, désolé..

On peut le mettre dans une extension dédiée aussi, ça évite de modifier newtextsearch et ça permet aux 4-5 personnes intéressées d'avoir accès à la fonctionnalité (je pense à @EdmondAgate, @furax37 @AudreyAuriault @LouiseQuincaillere @MelanieMichel ...)

[EdmondAgate]

Hello Je n'ai pas trop l'habitude de relire des specs (donc un peu dur d'etre sur que rien ne manque) mais cela me semble bien correspondre aux besoins @J9rem constatés sur nos wikis :) ! Merci bcp @J9rem

@mrflos Un peu du mal à juger si je suis le seul à avoir ce besoin (enfin en tout cas beaucoup de nos partenaires Wiki l'attendent de pied ferme c'est sûr...), mais de mémoire lorsque cela avait été ajouté à https://yeswiki.net/?PageChantiersSurLefeu pas mal de personnes de la communauté étaient intéressées pour avoir un rendu type [Wilileurbanne ] (https://www.wikilleurbanne.fr/?wiki=MoteurRecherche&phrase=num%C3%A9rique) ; le besoin était bien de pouvoir diviser dans une recherche sur une gare centrale ce qui relève des èvènements, des acteurs, des pages de présentation etc. tout en excluant certains formulaires type inscription (pour nos besoins cela fait donc bien sens de "pouvoir discriminer les formulaires dans la recherche globale" ;)

Et si cela est plus souple pas de souci pour l'avoir dans une extension dédiée (avec le risque de multiplier les extension...) , je ne suis pas habilité à juger "le risque" que cela soit ajouté à un wiki standard

[mrflos]

Je ne dis pas que la fonctionnalité n'est pas utile, juste que l'implémentation se fait au mauvais endroit: les actions textsearch ou newtextsearch sont faites pour faire une recherche plein texte, et ne sont appelés que dans une seule page, RechercheTexte, qui est générique. Pour moi il aurait été plus intéressant de partir de l'action bazarliste et d'y ajouter des possibilités pour aussi rechercher des pages wiki, que de partir d'un code ou les fonctionnalités de templates, facette, query, correspondance, etc sont inexistantes.

Je pense que cela aurait plutot mérité une remise à plat du système de recherche, de filtre et de restitution des données dans yeswiki plutot que d'améliorer un bout dans un coin.

[J9rem]

@mrflos il semble, après relecture de tes commentaires, que la solution retenue ne correspond pas au besoin de concertation que tu soulèves et qui est pertinent. Du coup mieux vaut sans doute rester sur une extension custom (le temps que la concertation ait lieu)

Je propose donc la clôture de cette PR (avec @EdmondAgate nous travaillerons avec la spec. sur nos PAD de travail)

[mrflos]

Ce que je peux vous proposer sinon, c'est que tu puisses intégrer des changements là sans faire de breaking changes (le comportement par défaut reste l'ancien), mais on se prévoit pour ectoplasme un travail de fond sur la restitution des données, pour permettre de faire un mix entre du bazar et des pages wiki, utiliser les templates, ajouter la recherche plein texte, etc

[J9rem]

effectivement, pour ceci, il suffit juste que le template par défaut soit le template standard

[mrflos]

Si vous etes ok pour garder le comportement par défaut, allez y, mais par ailleurs je trouve quand même les options proposées "exotiques", comme cette double limite entre les limites globales et les limites par type, je trouve que cela complexifie alors que justement sur une page avec des infos triées, on peut en afficher plus. Il me semblerait plus logique de n'avoir qu'un paramètre limit qui est la limite pour chaque type de fiche

[J9rem]

@mrflos est-ce que tu serais OK pour mettre le paramètre limit en paramètres avancés avec une valeur haute de type 300 ? L'idée est d'éviter de charger trop de pages sur les gros sites (et surtout, il nous faudra le garder pour la retrocompatilité)

je trouve quand même les options proposées "exotiques"

je suppose que tu parles de ce qui concerne les tags ? displaytypes titles nbbytypes comme intention c'est pas exotique j'ai l'impression sauf pour le réglage sur les tags.

A la rigueur, on peut garder ceci en custom.

juste que je vais renommer displaytype en typeofview pour éviter les confusions possibles

[mrflos]

c'était en particulier nbbytypes et limit qui pourraient etre qu'un seul paramètre. Si on est dans une recherche, on veut pourvoir voir tous les resultats, donc je suppose que cette limite est une pagination pour éviter de trop charger les pages, sinon ca fait pas de sens, certains résultats pour peux qu'ils soient trop vieux n’apparaîtront jamais. Pour les noms displaytype en contenttype peut etre? enfin, pour les ancres, je pense qu'un paramètre get est plus approprié qu'un handler, qui va complexifier la maintenance

[J9rem]

@mrflos @EdmondAgate j'ai mis à jour la présente PR qui passe maintenant en statut "prête à relire"

@mrflos je crois que tu n'es pas disponible pour la relecture. Les modifications du code doivent normalement suivre les préconisations que nous avons en cours pour YesWiki (mais je eux toujours avoir fait des erreurs). Je pense que cette PR a plus besoin d'une relecture par des usagers avancés pour valider les modifications qu'elle apporte, je vais m'orienter vers @gatienbataille ou @furax37 si c'est bon pour toi ?

A noter, (j'ai mis à jour le commentaire de tête), l'affichage est maintenant dynamique en incluant toutes les options proposées dans le PR et j'ai tenu compte de la remarque de @mrflos de ne pas créer de nouvel handler (j'ai crée des post handler show__ et iframe__ pour rajouter les ancres à la volée)

Merci d'avance pour vos remarques.

je suis convaincu que de nombreuses personnes seront contentes d'utiliser ces améliorations si elles sont dans le coeur. Je pense à @MelanieMichel (qui pourrait le confirmer ici pour appuyer ma proposition d'amélioration)

[J9rem]

@mrflos merci pour tes remarque sur le code.

Effectivement, j'ai oublié de préciser que je suis obligé d'appeler les posthandler pour être sûr de passer après les handlers des extensions ou custom. Mais c'est peut-être une contrainte trop forte et je peux le déplacer dans les handlers principaux.

Concernant le gros preg, il n'est appelé que si on en a besoin (avec le $_GET['searchAnchor']). Donc pas de consommation de ressource pour rien.

[J9rem]

le nom de l'action newtextsearch va mal vieillir, peut etre un truc comme CategorizedSearch ou TypedSearch serait plus adapté.

L'intention est belle et bien de remplacer l'actuel NewTextSearch, on peut changer de nom. Aucun souci. J'intégrerai alors un alias {{newtextsearch}} renverra vers le nouveau nom en interne pour garder la compatibilité avec les pages existantes qui utiliserait newtextsearch

[J9rem]

@mrflos peut-être préfères-tu que je commence par proposer le contenu de ce correctif dans une extension YesWiki sur le dépôt officiel puis, quand et si l'extension sera suffisamment demandée par la communauté, nous l'intégrerons dans le coeur.

[mrflos]

Si c'est rapide, oui, si c'est contraignant, on demande à @gatienbataille et @furax37 de statuer d'un point de vue utilisateur s'il faut mettre cette feature de 4.4.
Ca irait?

[J9rem]

@mrflos hyper facile de faire une extension dédié (ça me prendra 10 minutes vu que je l'ai déjà). Est-ce que le nom de newtextsearch te conviendrait ?

[mrflos]

si elle s'appelait déja comme ca, pourquoi pas, mais je disais que le nom ne sera plus valable quand il y aura des nouveautés sur la recherche. Peut etre advancedsearch ? ou typedsearch ?

[J9rem]

ok pour advancedsearch, je mettrai l'extension en début de semaine pour doryphore-test et quand on fera doryphore 4.3 on pourra la rajouter pour doryphore.

Je passerai la présente PR en statut draft

[mrflos]

tu peux mettre les extensions de partout ou ca marche, je pense que doryphore et doryphore-test seraient appropriées

[J9rem]

nouvelle extension créée : https://github.com/YesWiki/yeswiki-extension-advancedsearch pour doryphore-test et testing. Cette extension sera pleinement fonctionnelle à partir de doryphore 4.3

[J9rem]

je clos cette PR vue que l'extension advancedsearch fait le travail et je supprime la branche associée pour éviter les confusions (en plus, il n'y a pas de prévision d'intégration prochaine dans le coeur, donc inutile de maintenir une branche de travail dédiée)