MeatballWiki |
RecentChanges |
Random Page |
Indices |
Categories
EditThisPage est le Cri de Ralliement de
DaveWiner de
ScriptingNews.
Aussi utilisé dans les wikis. L'objetctif est que le contenu devrait être
modifiable/éditable via un navigateur. Par conséquent vous n'avez pas besoin d'outils de développements pour maintenir un site. Un geek avec SSH Apache, Linux et Vi n'a pas besoin de tout ça, mais même ensuite, HTTP est là où réside le trou dans le pare-feu.
- Mieux de disposer de canaux séparés de lecture et lecture-écriture. Vous devez permettre l'accès public à l'un, mais pas à l'autre.
- Vous êtes ainsi en désaccord avec les wikis ?
- Non - Je les aime pour des cas spéciaux. Je n'aime pas les choses comme les extensions WebDAV? et Frontpage, ou même la méthode PUT en HTTP. Très facile à abuser et pas suffisamment de fonctionnalités pour être vraiment utiles (les extensions FP et WebDAV? peuvent avoir les fonctionnalités, mais elles ne sont simplement pas bien implémentées.)
- Je pense que ce mode NORMAL pour modifier le contenu web ne devrait pas se faire via HTTP. La plupart du contenu web ne devrait pas être modifiable par le lecteur - imaginez si je pouvais éditer www.cnn.com. Si les sites individuels désirent produire des interfaces spéciales, laissez-les faire (un site web admin pour la publication d'articles, etc.) Les commentaires de l'émetteur original signifiaent de penser tout faire rouler à l'intérieur d'un grand protocole était la façon d'y aller. Je préfère de loin disposer de plusieurs protocoles, petits, faciles à implémenter (et à débugger et sûrs)
Oui, sous Manila (UserlandManila?, pour le wikifier), la section édition est sous une protection par mot de passe. C'est ce que j'ai fait avec beaucoup de mes pages. --DaveJacoby
- Et vous utilisez la méthode POST normale pour l'implémenter, c'est bien ça ? Pas besoin de PUT. Et si vous voulez vraiment le sécuriser vous pouvez exiger que ces requêtes d'éditions soient authentifiées et portent les éditions via HTTPS au lieu du HTTP. Les clients scp(1) existent pour tout sous le soleil, aussi si vous ne voulez pas coder la section d'édition sous HTTP, vous avez là une alternative très sécurisée. Il n'y a simplement pas besoin de protocoles compliqués qui essayent de tout faire. Regardez les monstres comme IPSEC et SSL. Ils sont laids et difficiles à implémenter. Des protocoles comme SSH, HTTP et telnet sont bien meilleurs. (La spec SSH est particulièrement jolie, même si j'aurais préféré une négociation fondée sur ASCII, simplement pour la clarté de programmation).
Sur la plupart des wikis, EditerCettePage introduit un mode : vous pouvez regarder le même contenu avec un affichage non-éditable et agréable, ou sur un mode éditable et "brut". Tout comme cela échoue à être un WysiwygWiki, cela échoue aussi à être vraiment une "InterfaceHumaine". Beaucoup de wikis Wysiwyg ont séparé les modes "édition" et "lecture-seule". Néanmoins, réduire les modes en ayant seulement un mode éditable irait peut-être trop loin pour la PropositionFacile : ceci peut indiquer un conflit entre une InterfaceHumaine et une confiance sur la SécuritéDouce par une SécuritéParObscurité, des BilletsGuide, des PortesNonverrouillées?, etc.
LangueFrançaise PageTranslation EditThisPage
Pour information en
LangueFrançaise,
EditThisPage se traduit :
L'AcadémieWiki? est naturellement invitée à éclairer et relire attentivement la traduction de cette page pour bien traduire Edit en LangueFrançaise. Le lien original est EditThisPage. Notons aussi que s'il y avait une InterfaceHumaine de MeatballWiki en LangueFrançaise, je proposerais bien de traduire "Edit text of this page" par "Éditer le texte de cette page" (avec un accent aigu sur le É mais là je n'ai pas de clavier humain pour l'écrire !). Naturellement, cela peut être discuté pour le futur EspaceNom francophone du MeatballWiki.
-- ChristopheDucamp