わざわざ残す必要もないことを整理とか気にせずに吐き出していく。そんな空間。

yamlからobjectを生成するQuinaとかいうライブラリを作ってる話

昔っからCMS構想とかいろいろ考えてるものの、 何を動作っても、「いやそれって結局Wordpressのほうがよくね?」みたいになってしまって 挫折を繰り返しているmikakaneです。

結局どんなにソースが汚いレガシーだろうと、あのプラグイン数やテーマ数には勝ち目がないわけですし、何よりもやっぱり「動く」ほうが偉い、ってわけなんですよね。

ドキュメント管理をYamlでやりたいという思いは昔からあったのですが、 JekyllはRubyで触りたくないし、DB使わないとかいみわからない、というかfuelphp使いたいし、とかいう思いがあるので、PHPで何とかならないかなぁと苦心していたところ、 メタプログラミングやらDIやらAnsibleやらに出会い、 とうとう、Yamlでオブジェクトを記述するとかいう、ちょっと良くわからない境地にたどり着きました。 いや、ほんとにAnsibleはすごいです。

https://github.com/mikakane/quina

このquinaとかいう名前のリポジトリは過去に3-4回ほど消されては復活し、消されては復活しと、 自分の中のやりたいことリストの中でもふらふらとしているやつです。

記法としては、module名: パラメータ的な具合で書かれたYamlを読み込むと、そのモジュールを全部持ってるオブジェクトを生成するよ、というシンプルなやつ。

パラメータはモジュールのファクトリにそのまま渡されます。

んでもって例えば、breadcrumbモジュールの場合、

use Quina\Quina;

// breadcrumbモジュールのデフォルト静的メソドをコール
Quina::breadcrumb();

// breadcrumbモジュールのinvokeを実行
$quina->breadcrumb(); 

//breadcrumbモジュールのオブジェクトを取得
$breadcrumb = $quina->getModule("breadcrumb"); 

みたいな感じで各モジュールにアクセスできます。

モジュール名は基本クラス名ですが、名前空間もあるのでモジュール名前空間や短縮名の定義も可能。他にもyamlを読み込むbaseディレクトリとかも設定で差し込めます。 ただ、フレームワークと連携して使う想定上、設定クラスがinterface定義で実体がなく、利用する際にConfigクラスから記述する必要があります(といってもinitとget程度)。

これでドキュメント書いてCMSっぽくしていったら、何かと捗るんじゃね?みたいに思いながら、ぼちぼちやっておるのが最近でございます。