Gestion du linktracking par rapport aux actions

Jusque dans la version 0.4.3 de WikiNi, l'utilisation des méthodes start- et stoplinktracking de la ClasseWiki était totalement sans effet (voir RapportsDeBogues). Ceci avait pour conséquence que les liens générés par les actions étaient trackés comme n'importe quel autre lien.
Normalement, ce n'est pas le cas, car la méthode Action de la classe Wiki nécessite (peut-être pas dans les anciennes versions de WikiNi...) un paramètre optionnel $forcelinktracking (je trouve que le nom est mal choisi mais bon...) qui, s'il n'est pas spécifié, doit normalement provoquer l'arrêt du tracking des liens. Or (à première vue, dans la classe wiki et dans le formatter wakka) il n'est jamais spécifié ! Donc toutes les actions, ainsi que les entêtes et les pieds de pages (qui sont aussi des actions) ne devraient normalement pas générer de liens trackés. Cependant, actuellement, ils le sont tout de même...
Ceci devrait, je l'espère, être corrigé dans la prochaine version de WikiNi (suivez le WikiNiChangeLog050)

Cette page va tenter de détailler les effets que cela provoquait, et les choses à modifier (ou déjà modifiées)

Effets sur l'entête et le pied de page

Tous les liens se trouvant dans l'entête et le pied de page étaient trackés sur toutes les pages (voir par exemple les BacklinksPagePrincipale), ceci est particulièrement lourd: un enrégistrement supplémentaire dans la base de données par page et par lien se trouvant dans l'entête ou le pied de page. Concrètement, pour un WikiNi de 1000 pages ayant conservé les options par défaut, cela fait 4000 enrégistrements inutiles: la PagePrincipale ainsi que les DerniersChangements, les DerniersCommentaires et les ParametresUtilisateur se retrouvent en effet tous les 4 liées à chacune des 1000 pages...

D'un autre côté, cela avait aussi son avantage:

• Le nom du propriétaire, qui apparaît dans le pied de page, était considéré comme un lien appartenant à la page
• Le nom de l'éditeur, qui apparait dans l'entête ("Vous êtes..."), était, lui aussi, considéré comme un lien de la page
  • Même s'il n'était pas connecté ! Or dans ce cas il peut y avoir des NomWiki dedans. Par exemple, si on résoud mon ip, on obtient quelque chose du genre:
    • ***-***-***-***.Namur.GoPlus.FastDSL.tiscali.be, il y a deux NomWiki dedans !
      • (un anonyme vient d'ailleurs aujourd'hui [2004-12-27] d'éditer les ContributionsAvancees avec une adresse de ce type)
  • Ce qui avait entre autres parfois pour effet d'ajouter inutilement des PagesACreer...

Ces deux avantages permettaient à n'importe qui de lister facilement toutes les pages auxquelles il a participé (à condition qu'il soit l'auteur de la dernière révision s'il n'en est pas le propriétaire, mais en général on signe de toute façon ses modifications...)

Voici quelques détails sur les modifications (de fonctionnement) que j'ai faites dans le handler edit (voir WikiNiChangeLog050) qui est en fait le seul "responsable" du linktracking:

• Les entêtes et le pied de page ne sont plus générés de façon interne pour le tracking, ce qui a trois conséquences:
  • gros gain de performances à l'édition: moins de code PhP à exécuter, moins de requêtes MySQL...
  • les liens donnés dans l'entête et le pied de page ne sont plus trackés
  • quand la correction du bug concernant le linktracking sera faite (voir mon dernier RapportsDeBogues), l'effet du handler edit ne sera pas altéré.
• Lors du formattage interne, le résultat du formattage n'est plus stocké pour rien dans une variable $dummy dont on ne se servira pas plus tard...
• On vérifie si l'utilisateur courant est connecté avant de tracker le lien vers sa page personnelle
• On vérifie que la page a un propriétaire et on tracke ensuite le lien vers sa page personnelle.
  • Et si c'est une nouvelle page ? Alors le lien sera quand même tracké puisque ce sera l'utilisateur courant qui deviendra proprio...

Les autres modifications sont assez mineures, car même si le diff montre que tout a l'air d'avoir changé, j'ai en fait surtout déplacé des bouts de code sans vraiment les modifier...

Effets sur les actions en général

L'effet actuel est que tous les liens générés par des actions via la méthode Format(), ainsi que ceux générés via les méthodes Link() et ComposeLinkToPage() sans fournir le 4e argument sont d'office trackés...

Suggestions pour le développement à venir:

• Certaines actions peuvent logiquement tracker les liens, d'autres non et d'autre encore tracker une partie mais pas tous. Il n'y a pas de raison qu'a priori ce soit le formatter qui décide s'il faut les tracker (via le second argument de la méthode Action()), on devrait plutôt laisser l'Action décider par elle-même, et donc modifier en conséquence les actions existantes... (sinon, d'ailleurs, le comportement du linktracking par rapport aux actions va être considérablement affecté par la correction du bug...)
• Le linktracking n'est utile qu'au moment de l'édition, donc ce devrait être au handler de décider d'activer ou désactiver initialement celui-ci. Ensuite certaines actions pourraient le désactiver si nécessaire...
• Lorsqu'on tracke les liens pour les enrégistrer (c'est à dire lors de la sauvegarde d'une page), on n'a normalement pas besoin de générer le code html en sortie. On pourrait envisager une variable de classe (ou une méthode) permettant de savoir à tout instant si on a besoin du contenu en sortie, de sorte que le formatter sache s'il peut se contenter de détecter les liens et les actions ou s'il doit tout formatter, et que les actions ne s'exécutent pas entièrement mais ne fassent que générer les liens. Cela permettrait d'ailleurs de réduire considérablement le nombre de requêtes lors de la sauvegarde d'une page, puisqu'il n'y aurait plus besoin de vérifier l'existance de toutes les pages liées à ce moment là.

---