AncrePermanente

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Cette page a démarré sur PermanentAnchor

Les ancres permanentes permettent aux personnes de lier vers une ancre spécifique sur une page. Le lien vers ce lieu restera valide, même si l'ancre est migrée vers une autre page, à la différence des ancres-noms simples comme utilisées dans le HTML.

Voir aussi PermanentAnchorDiscussion en anglais pour la discussion qui mènera à l'adaptation de cette page.

Description

Les AncresNomméesEnWiki normales dépendent de leurs pages hôtes pour que suffisamment de contexte puisse être résolu. Par exemple, l'ancre#carnet n'a pas le même sens sans sa page hôte associée : SunirShah#diary. Il est attendu et désiré de limiter le champ des ancres à leurs contextes locaux -- si l'on prend les potentiels de conflits comme AlexSchroeder#carnet-- ceci nous conduit à certains inconvénients lors de l'édition. Vous pouvez mettre fin à ça en migrant une ancre d'une page à une autre, cassant par conséquent tous ces liens vers elle à partir d'autres endroits, que ce soit à l'intérieur du wiki comme à l'extérieur. Par exemple, Sunir a une tendance à lâcher des ancres tout au long de son journal en ligne, telle que #amsterdam pour le billet correspondant à sa visite à Amsterdam. Néanmoins, SunirShah#amsterdam n'existe plus sur son journal parce que le billet a migré vers SunirGoesToEurope?.

Une ancre permanente sur un wiki ressemble beaucoup aux AncresNomméesEnWiki, si ce n'est que ces ancres n'ont pas besoin de page hôte pour être retrouvée. Elles existent dans un contexte global, beaucoup plus proche des titres eux-mêmes. En fait, deux implémentations sont possibles ici :

Le fait de visiter une ancre permanente est une action spécifique, par conséquent les ancres permanentes vivent dans un second espace-nom différent de l'espace-nom de la page.
Les ancres permanentes fonctionnent comme un AliasPage? avec la capacité supplémentaire de renvoyer vers une position à l'intérieur d'une page. Les pages et les ancres permanentes partagent le même espace-nom.

Les ancres permanentes fournissent une nouvelle structure très intéressante pour les wikis. Alors que la DatabasePage fournit une organisation top-down des contenus du wiki, organisé en de petits morceaux discrets autour de chaque nom de page, les ancres permanentes fournissent une organisation bottom-up des contenus, organisés dans des singularités fluides. La flexibilité supplémentaire qu'elles fournissent peut permettre de nouvelles conventions de structures non racontées, comprenant probablement de meilleurs WikiLogs.

Syntaxe pour Pointer vers des Ancres Permanentes

Comme indiqué ci-dessus, les liens vers des ancres permanentes peuvent simplement ressembler à des liens ordinaires vers des pages, s'ils partagent le même espace-nom.

S'il vivent dans un second espace-nom, une certaine forme de syntaxte est requise pour annoncer un lien vers une ancre permanente. Du fait de leur similarité à des titres de page, il peut être bien de coopter la syntaxe ModèleDeLien pour une AncrePermanente en utilisant un numéro en tête suivi par une page-nom : #ModèleDeLien.

Cette syntaxe pourrait coexister avec des ancres locales "réelles" telles que #carnetweb. La seule contrainte est que les vraies ancres locales nommées peuvent ne pas concorder avec le ModèleDeLien.

Une autre syntaxe potentielle est ?ModèleDeLien parce que cela reflète la partie requête de l'UniformResourceIdentifier qui est une partie critique de l'interface de la plupart des wikis. Bien sûr, cela requiert que les AncrePermanentes partagent le même espace-nom comme le reste de la DatabasePage, ce qui est une innovation d'OddMuse.

Peut-être une syntaxe plus évidente sera meilleure. OddMuse utilisait précédemment [##ancre].

URL pour ancres permanentes

Une idée initiale était de passer la forme #ModèleDeLien directement dans le programme, mais c'est dangereux. L'url http://usemod.com/cgi-bin/mb.pl?#SunirGoesToAmsterdam non seulement viole la RFC pour UniformResourceLocators mais le fragment #SunirGoesToAmsterdam doit être utilisé par l'agent utilisateur, ainsi le serveur et le script pourrait ne pas pouvoir le retrouver selon le comportement de l'agent utilisateur, du serveur, proxy et ainsi de suite.

Le schéma url le moins attractif http://usemod.com/cgi-bin/mb.pl?action=browse&anchor=SunirGoesToAmsterdam a des inconvénients ce qui est embarassant. Si le système AncrePermanente est sensé être une ressource, il devrait être aussi facile à utiliser que la ressource normale ModèleDeLien.

Pour examiner ce dernier énoncé plus précisément, imaginez le UseCase important pour les AncrePermanentes de quand nous classer une PagePeuProfonde à l'intérieur d'une autre page plus grande. Ici, nous coupons et collons le texte d'une PagePeuProfonde dans une section sur l'autre page hôte, rendant le titre de la PagePeuProfonde une AncrePermanente sur la page hôte. Parce que les bonnes URLs sont permanentes, la même URL pour la PagePeuProfonde pourrait diriger le navigateur vers l'AncrePermanente le texte tombe maintenant sous par ex. mb.pl?MaPage et mb.pl?MonAncre De ce fait, les AncrePermanentes devraient exister dans le même espace-nom que le reste de la DatabasePage et le schéma URL est équivalent.

Quand le script est alimenté, l'URL mb.pl?MonAncre, bien sûr ce n'est pas le cas qu'il devrait charger la page page MonAncre, parce qu'elle n'existe pas. A la place, il devrait rediriger le navigateur vers mb.pl?MaPage#MonAncre. Néansmoins, nous faisons face à une difficulté en ce fait que quelques navigateurs ne prennent pas l'ancre en considération durant la redirectio, même si RFC 2616, section 10.3.3 "302 Found", indiques que la redirection utilisant des ancres devrait fonctionnet tout le temps. Le client devrait simplement faire un autre GET sur l'URI donnée dans le champ Location. Tout ce qui reste est un bug dans le client.

Une solution laide à cela est durant la traduction de syntaxe, nous pourrions théoriquement avoir les liens script vers l'URL véritable quand elle rencontre des AncrePermanentes. Ce qui veut dire que quand elle voit un ModèleDeLien, il vérifie d'abord si ou non c'est une AncrePermanente. Si non, il pourrait émettre mb.pl?ModèleDeLien ; Si c'est oui, il émettrait mb.pl?MaPage#ModèleDeLien. Ce hack est laid car il brise l'idée que les AncrePermanentes sont des adresses dedans et d'elles-mêmes, et par conséquent permanentes. Par exemple, les SpiderBot?s devraient enregistrer l'URL permanente future, pas où nous sommes actuellement en train de stocker l'information.

Une solution ?

Un contournement pourrait être d'utiliser mb.pl?anchor=SunirGoesToAmsterdam#SunirGoesToAmsterdam. Ajouter un lien à lui-même vers l'ancre permanente est peut-être une bonne idée dans ce cas car l'url est un peu embêtante.

Pourquoi ne pouvez-vous pas simplement utiliser mb.pl?SunirGoesToAmsterdam#SunirGoesToAmsterdam. Cela permettrait de lier vers des ancres permanentes aussi facilement que vers une page complète : assembler simplement les mots ensemble. --MartinHarper

Oui, comme le ExternalReferral? je vais simplement lier vers MeatBall:MonAncre, pas MeatBall:MonAncre#MyAncre. Imaginez le cas d'utilisation de la PagePeuProfonde : MeatBall:MyShallowPage devrait encore fonctionner après le retravail. -- SunirShah

Organiser les Ancres Permanentes

Le problème bien sûr est de faire ça efficacement. Dans le pire des cas, le programme pourrait rechercher dans toute la datebase page pour l'ancre. Néanmoins c'est inefficace. Une meilleure réponse est de traduire chaque page au moment de la sauvegarde pour extraire toutes les AncrePermanentes sur cette page là. Puis de simplement créer une petite base de données AncrePermanente qui gère simplement le nom de la page hôte pour chaque ancre. De cette façon, au moment de chercher une ancre permanente, le script n'a seulement besoin que de regarder dans la basd de données ancre pour cette entrée, de tirer le nom de la page hôte et de la charger, une opération O(1).

Un autre problème est que les AncrePermanentes ne sont pas garanties pour être uniques. Quelques options sont disponibles ici. Une option est de simplement empêcher les duplications, comme en affichant un dialogue de ConflitEdition au moment d'essayer de créer une AncrePermanente déjà utilisée. Alternativement, un simple message d'alerte pourrait être affiché, même si ceci a le potentiel d'être raté ou ignoré. Peut-être que dans la "plus" InterfaceHumaine, le script pourrait simplement charger le texte de la page hôte précédente, ôter l'ancre et resauvegarder cette page sans sauvegarder la nouvelle position de l'ancre. La modification serait listée naturellement sur les ModificationsRécentes. Voir section "Conflits Nom" en-dessous pour en savoir plus

Syntaxe et Rendu pour des Définitions des Ancres Permanentes

Si #QuelqueAncre est déjà utilisé pour pointer vers des ancres permanentes, alors une autre syntaxe est requise pour les définir.

Quand l'URL pointant vers une ancre est compliquée, la définition de l'ancre peut simplement pointer vers elle-même. Ceci faciliterait de copier l'endroit du lien en utilisant un navigateur et l'utiliserait ailleurs.

En outre, la définition peut être rendue en utilisant une icône avec un texte intéressant ALT, ou comme un lien avec une classe spéciale CSS qui peut être utilisée pour modifier l'apparence. Le texte indiquerait que c'est un "Lien Permanent" et le moyen préféré de lier vers ce morceau spécifique de texte.

OddMuse utilise [::QuelqueAncre] pour définir une ancre permanente. Au rendu, ceci agit comme un titre de page ordinaire : il cherche les rétroliens.

Martin Harper a proposé une syntaxe utilisant le texte pour un AliasPage?. Ce qui suit définirait l'alias page MyRedDice :

    PageAlias MyRedDice?

Mettez cela en perspective avec les PurpleNumbers, là où les ancres sont créées automatiquement.

Conflits de Nom

Quand des doublons émergent, le lien devrait être remplacé avec un petit message d'alerte et un lien vers l'autre occurence de cette ancre permanente. Ceci serait une meilleure InterfaceHumaine -- pas de message d'erreur, pas d'interruption.

Expérience

Sur le EmacsWiki, personne n'utilise d'ancres permanentes. Le seul bon usage qu'ils ont mis était un glossaire sur wik ICT4, et les ancres pour toutes les options dans le mode d'emploi de OddMuse. Pourquoi ça ? Les ancres permanentes exigent de vous de résoudre les problèmes futurs. Supposez que vous avez deux sujets A et B sur la page un. Maintenant vous migrez le sujet B en page deux. S'ils ne veulent pas éviter des tonnes de liens cassés vers B, ils pourraient vouloir utiliser des ancres permanentes pour cela. Le problème est que vous devez penser préalablement à propos de la création d'une ancre permanente pour B dans l'intervalle de temps séparant l'écriture à propos de B sur la page un, et le premier lien vers la page un renvoyant vers le sujet B seulement.

Les ancres permanentes peuvent cependant remplacer les RedirectionPage. Supposez que vous migriez le contenu d'une page A vers une page B. Vous pouvez maintenant édier la page A et placer une redirection de page de A vers B ici. En utilisant les ancres permanentes nouvelles où les ancres et les pages sont dans le même espace-nom, vous pouvez effacer la page A et créer une ancre permanente appélée A sur la page B. Voir AliasPage? pour en savoir plus

Voir aussi AnnotationNommée pour un modèle d'usage proposé.

Commentaires

C'est fascinant (pour moi) d'essayer de produire un meilleur RedirectionPage et d'essayer de produire de meileures AncresNomméesEnWiki qui tous les deux mènent à la même chose. Je ne peux pas décider si c'est un bon FeatureKarma. -- MartinHarper

Voir aussi PageAlias (AliasPage? ou CommunityWiki:AliasPage en français)

LangueFrançaise PageTranslation PermanentAnchor DossierTechnologieWiki DossierTechnologieWikiNoncommune