開発談義の過去ログその9
- svn移行まだですか？ => (BugTrack2/214 Subversion 関連のまとめ)
- Wikimania 2007が発表者を募集 -- yahoo
- WikiPedia(MediaWiki)の簡単な整形ルールに対応した... ( => BugTrack2/234)
- pukiwiki-1.4.7_notbでは，添付されているlib/trackback.phpですが，CVSのMAINブランチでは既にlib/trackback.php及びplugin/tb.inc.phpが削除。CVSのUPDATING.txt,v 1.43では，TrackBack実装は完全に削除となっています。lib/trackback.phpに依存したプラグインは今後，どのように対処したら良いでしょうか？*1 -- g@kko
- lib/trackback.php についてこちらが挙げた疑義に納得していただいておるならば、それ依存したプラグインは、基本的に共倒れになるしかありません。そのプラグインを書いた方が独自に書いた部分以外の部分が欠片も残らないよう、ザックリ消して下さい。 -- henoheno
- TrackBackの再実装をされたいのであれば、TrackBack development のコードだけを参考にして、まさに単純なpingを飛ばしたり、受けるだけのシンプルなactionプラグインを作成される所あたりからお始めになると良いでしょう(過程が明確であれば誰も口をはさまないでしょう)。*2 -- henoheno
- ご回答ありがとうございます。これからの指針にいたします。もう１点，質問させてください。シビアな点になりますが。。。既存（だった）機能との互換性について，どのようにお考えですか？既存のデータ，既存のtrackback URLはそのまま使える方がユーザにやさしいと思いますが，前述された「欠片も残らないよう、ザックリ消す」ということであれば，非互換もやむなし*3ということでしょうか？*4 -- g@kko
- pukiwiki:自作プラグイン/include_module.inc.phpで話題にしていますSmartyテンプレートエンジンの実装とモジュール機能の実現を是非考えていただきたいと思います。 -- kahata
- pukiwikiへのSmartyの実装と使用環境整備はそれほど難しくないと思います。Starty自体のサイズは約1MBでそれほど大きくなく、現にxoopsではパッケージに同梱されて使用環境が整っています。 -- kahata
- 問題はwikiシステム上でどう使うかでしょう。モジュールの仕様をどうするか、既存のページやプラグインとの整合性をどうとるかが思案のポイントと思います。 -- kahata
- こんにちは。実はご提案の新規性があまり解っていません。一言でいうと、既存のSmartyネタと比べるとどの辺がいいのでしょう。もしお暇なら SiteDev2 を触ってみて下さい。(私は触った事がありませんが、発想と実行力には毎回驚かされます) -- henoheno
- ref の URL指定時に画像サイズ取得についての拡張案です。 サイトの高速化とサイズ指定の汎用性を両立したい人向けでしょうか。 -- Kjm
// URL指定時に画像サイズを取得するか
define('PLUGIN_REF_URL_GET_IMAGE_SIZE', TRUE); // FALSE, TRUE
+// PLUGIN_REF_URL_GET_IMAGE_SIZE==FALSE で、 URL指定時に画像サイズを取得するURL
+define('PLUGIN_REF_URL_GET_IMAGE_MATCH', '/^http\:\/\/[a-z][a-z][a-z]\.example\.com\/|http\:\/\/upload\.wikimedia\.org\//');
- if ($is_image && PLUGIN_REF_URL_GET_IMAGE_SIZE && (bool)ini_get('allow_url_fopen')) {
+ if ($is_image && (PLUGIN_REF_URL_GET_IMAGE_SIZE || preg_match(PLUGIN_REF_URL_GET_IMAGE_MATCH, $name) ) && (bool)ini_get('allow_url_fopen')) {
- 1ページ中で使える見出し(大小混合)の合計は、64個までなのでしょうか？
途中からまとめて編集して、70個くらいになった時点でページが全く表示されなくなりました(事実上のブラクラ効果*5を発揮)。XP+IE6で発生です。 --
- ディスクが満杯のときもページ消失しないようにしてみました。http://d.hatena.ne.jp/akira_you/20080624#p1 -- akira_you
- official:RWiki で気になったのですが、RWiki でページ名からアドレスに変換されるとき、半角スペースは「%20」ではなく「+」がデフォルトなのでしょうか？それとも環境依存？InterWiki 機能だと「%20」にしか置き換えれないので、とりあえず「RD format」のページへのリンクを直書きに変えましたけど。 --
- 歴史的な事情および設計依存であろうと思います。 -- henoheno
- まず、「Wikiのページ名のようなモノにどんな文字が使えるのか」という部分の設計がプロダクトごとに異なります。
- その中に「URIに使ってはいけない文字」が含まれている場合、何らかのエンコード(変換)によってそれを回避しなければ、「URIによって『その文字列』ひいては『そのページ』を指し示す」事ができません。
- こうした中で、「どのようなエンコードを使うか」という設計がプロダクトにによって異なります。
- 「どのようなエンコードを受け入れるのか」という設計も異なります。
- ※PukiWikiはエンコードの方法として、いわゆる percent-encode を採用しています。
- 初期の のWikiWikiWeb は WikiName というアイデアがベースになっていたためか、半角スペースをページ名として使いたい、という欲求がほとんど無かったようです(WikiNameしか受け付けない)。単語の区切りとしてのスペースはWikiNameの中に省略されており、大文字小文字の区切りによって類推できるのでたいてい問題無かったのでしょう。しかしそれにも不満はあった様で、WikiNameを構成する単語をページのタイトルとして表現する際に、自動的に半角スペースを挿入する工夫 が行われているものがちらほらあったかと思います。
Wikipedia MediaWiki ではスペースを "_" で表現できるようですが、これはそうした西欧の「単語の文化(スペースで区切る文化)」からのニーズをより強く反映しているのであろうと思います。
- さて、PukiWikiが持っているInterWikiの機構は現状 percent-encode にしか対応していません*6。これは現状のPukiWikiの内部機構をなぞっているだけであり、複数のエンコードに対応してはいけない、といった事情はありません。
- RWikiのようなサイト向けに、半角スペースを + に変換するような処理 (URLエンコード) ができたっていい
- 旧来のWikiWikiWebへのInterWikiであれば、半角スペースがあれば除去するような、またASCII文字列以外は除外するようなフィルタリングができたっていい
Wikipedia MediaWiki は percent-encode された半角スペースも受け入れてくれる様なので、あまり気にする必要は無いけれども、厳密には半角スペースをアンダースコアに置換したっていい
- エンコードの方法を変更する事は難しい事ではないでしょう。難しいのは、複数のエンコードを上手に使い分けられるように、InterWikiNameの設定文法を再設計したり、それをうまく読み取ったりする機構、つまりユーザーインターフェースの設計と実装でしょう。
- InterWikiNameの再設計のネタとしては、他に複数の置換要素 (${1} ,${2}, ${3}, ...) を用意するとか、InterWiki化したBracketNameの冗長な部分をうまくカットする工夫とか・・・この手の話はいろいろ工夫の余地があるだろうと思っています。
- zzz -- henoheno
:CategoryDev
と，いうか個人的にはTrackBackを再実装をしたいと切に願っているのですが。。。
折角なので一から考えていただきたいのは、WikiでTrackBackができるとどのような「Wikiならではの」梃子の効果が起こるのか、とか、今までの外部動作が持っていたような「Wikiならではの」デメリットについてのケアをどうするか、といった辺りですね
むしろ推奨？
私は後者のような気がしています
ページどころか、ブラウザも表示されない？
あ・・・YukiWikiとかが若干あったような気も・・・
Last-modified: 2010-04-27 (火) 23:27:11
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
