Par analogie avec les
PropositionsDEvolutionDeLActionUserSettings, je propose une étude le l'
ActionListPages qui permet notemment de s'y retrouver facilement dans un site
WikiNi (index, arborescence...). Après cette étude, je suis d'accord de refaire l'action entièrement moi-même (ce qui, à première vue, va être inévitable...).
Pour éviter que cela traine, vu qu'il y a déjà pas mal d'idées qui ont été données au moment où je crée cette page, je laisse la discussion ouverte
jusqu'au 10 janvier(
rappel), après quoi, s'il n'y a pas d'objections, je commencerai le développement de la nouvelle version (qui, je pense, pourra rapidement être intégrée au cvs... Enfin, vu les difficultés au niveau de la
ProcedureDeDeveloppementDeWikiNi, on verra pour le "rapidement": ça dépend de la demande je pense, donc de vous) --
LordFarquaad
Etude de la version actuelle
Fonctionnalités
La version actuelle de l'
ActionListPages permet :
- d'établir un IndexDesPages classées par nom, date, propriétaire ou dernière personne à les avoir modifiées
- d'établir l'arborescence du site à partir de la PagePrincipale (voir PlanDuSite) ou de n'importe quelle page
Problèmes de performances et de fonctionnement
(à peu près dans l'ordre de la source)
- La fonction TreeView
- tente d'éviter de lister les pages ayant un lien dans l'entête du site, mais cela n'est pas du tout efficace car elle se base sur la configuration par défaut des 'navigation_links', qui suppose que les liens sont séparés par " :: " alors que cela peut très bien avoir été changé (notemment pour une ActionInclude...). Notez que les entêtes ne seront feront plus partie des liens de chaque page dans la prochaine version de WikiNi (voir WikiNiChangeLog050 et DevActionsEntetePiedDePageEtLinkTracking)
- indente la liste avec des " " au lieu d'utiliser simplement... des listes !
- effectue un requête sur chaque nom de page (qu'elle existe ou non d'ailleurs...) pour obtenir la liste de tous les liens qu'elle contient (il y a certainement moyen de ne faire qu'une requête par niveau)
- effectue cette requête même quand il s'agit du dernier niveau !
- Il y a à peu près deux fois le même code pour le cas où sort est spécifié et le cas où ni sort ni tree ne sont spécifiés. (il est d'ailleurs impossible de combiner tree et sort...)
- ...
Proposition d'évolution de l'action
Demande de fonctionnalités
Beaucoup de fonctionnalités ont été proposées dans les commentaires de l'
ActionListPages, à vous d'en proposer d'autres:
- Permettre de choisir le nombre de niveaux de l'arborescence
- Permettre de lister les pages dont tel utilisateur est le propriétaire (avec par exemple par défaut le propriétaire de la page courante. Notez que cela serait différent de l'ActionMyPages qui liste les pages de celui qui la regarde la page !)
- Un paramètre d'exclude comme dans l'ActionBacklinks
- Permettre de combiner l'arborescence avec l'option de classement (ça peut toujours servir...)
- Permettre de combiner l'arborescence avec l'option de propriétaire (peut-être un peu complexe...). Cela pourrait fonctionner comme ceci:
- On spécifie le propriétaire et éventuellement une page (par défaut la page du propriétaire, mais ça ne doit pas forcément être une page lui appartenant)
- L'action affiche l'arborescence, comme actuellement avec /tree, sauf qu'elle n'affiche que les pages dont la personne spécifiée est le propriétaire.
LordFarquaadASuivre
Développement de la nouvelle version
J'ai développé la partie sans l'arborescence, vous pouvez tester et télécharger la version en développement ici:
http://www.notredomaine.org/BacASableNewListPages
--
LordFarquaad
- Maj: j'ai fini ! J'ai actuélisé la page bac à sable et je l'ai mis en production sur le wiki que j'ai ouvert pour ma fac:
- J'ai programmé les choses de sorte de faire le moins de requêtes mysql possible (à savoir, en mode tree: 1 + nombre de niveaux; en mode "normal" 1 ou 2). La requête se charge donc de vérifier aussi si la page existe ou non et d'autres informations. Ceci permet d'éviter de vérifier l'existance de chaque page au cas par cas (ce que fait la méthode Link). L'inconvéniant est qu'il est actuellement impossible d'appeler une quelconque méthode de la ClasseWiki pour construire un lien de type "éditer" (avec un "?" après le nom de la page) sans que celle-ci ne fasse de requête mysql pour vérifier l'existance de la page. D'où les bouts de code répétés avec le span...
- -- LordFarquaad
- Au fait: normalement la compatibilité est conservée avec l'ancienne version. -- LordFarquaad
C'est vachement mieux qu'avant :) Est ca serait très compliqué de rajouter les arguments {{newlistpages owner=myself}} et {{newlistpages user=myself}} qui ramèneraient les mêmes résultats que
ActionMyPages et
ActionMyChanges ??? Tout rassembler dans la même requête ca me parait plus propre. --
BasHaq
- Si tu utilises {{newlistpages/owner}} ou {{newlistpages owner="owner"}} ça fait la liste des pages appartenant au proprio de la page courante (idem avec /user et user="user"). Notre qu'avec mypages et mychanges c'est les pages et les changements de celui qui voit la page qui sont afficher (exemple: la page perso de ProgFou: tu y vois tes changements et non les siens) -- LordFarquaad
- Ouioui, j'ai bien compris la différence : ta fonction gère la liste des pages et les changements appartenant au proprio de la page courante (ou d'un proprio precis) tandis que mypages et mychanges gère la liste des pages et les changements de celui qui voit. Donc finalement c'est la même chose avec juste un paramètre différent. D'ou ma question, est ce qu'il n'y a pas moyen de tout fusionner et de faire de mypages et mychanges des sous-fonctions de listpages ? Ainsi la gestion des pages (à moi, à toi, à tous) est réuni dans une seule fonction et mypages peut utiliser l'affichage en arborescence. --BasHaq
- Ah oui je vois mais ça ferait un peu redondant je trouve, à part mypages en arborescence. (mychanges en arborescence ce serait plus compliqué, puisque dans la version que j'ai faite il n'est pas possible d'utiliser user avec tree...) Mais serait-ce vraiment utile ? Question de compatibilité avec les versions antérieure, autant laisser les deux choses dans des actions séparées je trouve... -- LordFarquaad
Je pense qu'il faut encore affecter une classe de style pour chaque présentation (genre .index_pages et .index_arbo).
- Pourquoi pas, en gros il y a deux présentations, ce qui change c'est surtout les requêtes mysql. Il suffit d'ajouter cela dans les <ul> et ça sera bon -- LordFarquaad
Autre petite remarque :
<li>xxxxx</li>
me parait plus lisible, au débogage que
<li>
xxxxx
</li>
Peut-être question de goût...
- C'est vrai que dans le cas présent, vu qu'il n'y a jamais plus d'une ligne c'est peut-être mieux. En tout cas vu la quantité d'élément qu'il peut y avoir, cela pourrait tout de même économiser quelques ko à chaque affichage... -- LordFarquaad
Sinon je pense qu'on est pas loin de la fin. Peux-tu publier ton code dans cette page pour qu'on jette un oeil ?
--
CharlesNepote
- Le code fait 500 lignes en fait... Mais je l'ai déjà mis en ligne ici en fait: -- LordFarquaad