開発日記

[開発日記]
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28

2013/7/31 (水)

必要な処理を本体に組み込む試み

これまで、ページの競合検知処理や、一部のアンチスパム処理はプラグイン毎に実装したりしていました。このため、dev:BugTrack2/197のような問題が起きており、プラグイン側でわざわざ実装したりしなければならない状態でした。こうならないように、データーの内容のチェックも本体でやるべきだと考えています。

Adv.ではページ書き込み処理を全面的に書き直しました。Wiki.phpのWikiクラスのset関数で書き込むようにしています。それ以外の方法でのWikiへの記入は禁止としています。

ここに加えるべき機能がまだあるかもしれないので、当分アルファ版のリリースは先に送ります。

2013/6/23 (日)

新エンジン

PukiWiki Adv.次期バージョンは、コアエンジンをすべて書きなおしてあります。改良というか別物になってます。前のバージョンや無印版、Plus!との互換性は、legacy.phpで行なっていますが完全なものではありません。Plusの拡張命令が使われたプラグインの一部は動作しない可能性があります。

とくに、ヘッダー周りの処理は逐次出力する実装から、バッファに貯めこんでから出力する方式に変えたため正常に動作しない場合があります。(pkwk_common_headers()など)

この新エンジンの最大の特徴は、オブジェクト指向でコードが書きなおされている点です。そして、原則的に読み込む処理はget書き込む処理はset、というようにGetter/Setterメソッドで関数名を書き換えています。このため、よりコーディングがしやすくなっています。例えば、ページに書き込む処理は、

page_write(ページ名,内容,タイムスタンプ更新フラグ);

でしたが、今後は

use PukiWiki\Factory;
~中略~
$wiki = Factory::Wiki(ページ名);
$wiki->set(内容,タイムスタンプ更新フラグ);

というようになります。一見ソースが長くなっているようにみえるかもしれませんが、旧方式では、実際はページの存在チェックなどをpage_writeの処理の前に入れなければならないため、一度慣れれば旧方式よりもパターン化されたプログラミングでプラグインの開発ができます。

オブジェクト指向化とは、プログラミングの簡易化という目的ですが、spl_autoloadという機能を用いて必要なコードを必要な時だけ読み込んで実行する設計にするというのも兼ねています。このため理論上旧バージョンよりも高速に動作し、特にapcを導入しているサーバーではより一層高い効果が期待出来ます。

最後に、キャッシュ処理の強化とPlus!で追加された機能の統合の強化があります。自動リンクやオートグロッサリ、InterWikiNameなどもキャッシュしているため処理が軽くなっています。


次期バージョンは、2.0とします。当初は1.1として開発し、legacy.phpで互換性をとってあるとはいえ、あまりにもAPIを書き変えたので1.0系を名乗るには問題が多すぎるというのが理由です。スキン互換性もありません。

アルファ版のリリースは、スキンの書き換えが終了次第行います。(たぶん、今週末?)

2013/4/15 (月)

MathJaxのサポート

次期バージョンで、エンジンにAbicky氏のMathJaxプラグインを本体に組み込みました。

MathJax for PukiWiki
http://abicky.net/pukiwiki/plugins/index.php?mathjax.inc.php
https://github.com/abicky/mathjax_for_pukiwiki

なお、MathJaxのスクリプトは、出力されたコードにmathjax-eqクラスの要素が含まれる場合のみ動的に読みこむようにしてあります。このため、MathJaxが存在しないページで余計なスクリプトが読み込まれる心配はありません。

2013/4/3 (水)

Sarabande.jp: PukiWiki の開発プロジェクトの再建案」についてのAdv.としての回答

PukiWiki Adv.の最近の開発指針としては、オブジェクト化を第一にしています。Plus!のコードでファイル操作系の処理が処理系ごと書かれていてわかりにくかったので、まずはSplFileInfoクラスを派生させたFileクラスで書き換えることからはじめましたね。次に、Wiki構文をHTMLに変換する処理をRendererクラスに書き直しました。他にも結構いじってますが、クラス名のネーミングセンスの良し悪しはさておき、Plus!や無印版よりも読みやすくなっているはずです。

ただ、知名度が低いのか、需要がないのかよくわかりませんが、現在のところ、フォークして「こうしたらどうだ」と提案する人はあまりいませんね。それ以前にまだ、コードの書き直しも完了してないので、こちらとしても、仕様が安定していないため受け入れ体制もできていません。(コミットごとにファイル構造や関数名が大幅に変わってしまうことがありえるという状態)

古い PHP のバージョンに対応できない状態が続けば、ユーザーがセキュリティメンテナンスされておらず安全ではない古いPHP のバージョンを使うことを強制させることになるし、PHP 5.3 以降を対象とする PukiWiki のプラグインや別の CMS を導入しようとするユーザーの妨げになる。

おっしゃるとおりです。別のCMSに入れるには、グローバル変数が多いためそこを減らしていくことも必要です。

PukiWiki をもとにした派生プロジェクトがいくつか存在するので、方針としては、それらのプロジェクトと協力関係をつくれるようにすることだ。

無印版のリーダーのhenoheno氏の派生版に対する態度から考慮すると難しいと思います。そもそも、そういう態度が取れるならばPlus!の機能の多くが無印版にも取り入れられているでしょう。自分としては、もう諦めちゃってる感がありますね。だからこそ、互換性を考慮せず、エンジンを0から書き直せているわけですし。その辺の考え方が、Plus!との大きな違いです。

開発プロジェクトの改善案としては Github に移行し、派生プロジェクトとパーサーなどの独立した機能のライブラリやデータのために個別のリポジトリを用意し、Composer を使って構成管理できるようにすることである。

composerの仕組みを考えると他のPukiWikiとの連携は難しいと思います。composer自体__autoload関数の性質を応用したものなので、オブジェクト指向なコードでないと呼び出しには使えません。無印版や、Plus!からAdv.のコードをcomposerを通じて参照させることは可能です(グローバル変数が多いので厳密にはそうではない)がその逆はできません。Adv.としても、まだ機能ごとに処理を十分に分割できるレベルではないので厳しいですね。

ソースコードの改善に関しては、ほかのプロジェクトが開発しているフレームワークやライブラリを採用し、標準化をすすめ、新しく参加する開発者の学習コストを下げる。

Adv.では、オブジェクト指向化の他に、phpdoc形式で関数に処理内容を書くようにはしてありますが、十分ではありません。なかなか、そちらの方までリソースが回せません。無印版やPlus!で使われている旧関数との対応状況は、legacy.phpで各自確認してとしか言えない状態です。

ただ、Setter/Getterメソッドでコードを書いているため比較的わかりやすいと思います。


現在のAdv.の要約:協力者は欲しいけど、まだ受け入れられる状態でないところが歯痒い。

2013/3/17 (日)

ヘッダー

PukiWikiのヘッダーは原則的にpkwk_common_headers()を実行してその後content-typeを別途出力する実装になっています。しかし、認証系の実装ではそのままヘッダーを出力していたりとごちゃごちゃになっていたので、Zend\Http\Responseを通して実行するようにしました。添付されたファイルの出力などでは問題はないのですが、スキン出力でContent-Lengthの値が計算できないなど問題が発生していたので、今後スキンロジックも大幅に変更し、Zend\ViewModelを用いたものにします。このため、スキン互換性がありません。

1.0リリース時点で、無印版やPlusと互換性がないのにまた変えちゃっていいのか微妙ですが、まぁAdv.の知名度を考慮すれば問題ないかな。

2013/2/24 (日)

認証関連の処理をリファクタリング

ええ。もうすでに、無印版やPlus!の認証処理の原型を留めてないです。まず、無印版とPlus!のauth.cls.phpの統合から始めました。すると、閲覧権限を指定する似たような処理だけで4つもあり、ごちゃごちゃに使われていることがわかりました。PukiWikiではこういった権限管理をページ単位で行なっているためWikiクラスに閲覧/編集可能かの判定関数を移動させ、実際のロジックはAuthクラスで行う実装にしました。

例えば、このページは閲覧可能かを判定するとき、これまでは

edit_auth(ページ名);
edit_auth(ページ名,認証画面を出すか?,エラーを表示するか?);

だったり、

auth::is_page_editable(ページ名,ユーザ名,グループ名)

だったりと、いろいろな判定処理がありましたが、

$wiki = Factory::Wiki(ページ名);
$wiki->isReadable();	// 単に閲覧できるかをブーリアンで返す
$wiki->isReadable(true);	// 認証画面を表示する

というようにしました。どうやってユーザ名、グループ名を指定するのかは、認証状態に応じて自動判定するため意識する必要はありません。

また、AuthクラスでcheckPermissionという関数を用意し、今後ここを拡張することでプラグイン別の実行権限も指定できるようにしておきました。(現在はreadとeditのみ。)

というわけで、一部プラグイン互換性がありません。対応させるためには、プラグインのソースの先頭にuse PukiWiki\Auth\Auth;という行を加え、auth::で始まる関数をAuth::で始まる関数に変更する必要があります。(認証系を使うプラグインを作る人はそう多くいないので、あまり影響ないかもしれませんが。)

本当、説明するのもややこしいので、そのうちPukiWiki Adv.phpDocでも作っておきます。

おまけとして、role_adm_contentsをrole_contents_adminに変更しました。管理人のコンテンツではなく、コンテンツの管理人という意味で使われているからです。結構混乱した人も多いのでは?