現状のConfigのneedsBookmark()のIFはこうなっている。
function needsBookmark($page = null, $aci = "*")
で、$pageが省略された場合はStory全体のBookmark ON/OFFを取得し、$pageが指定された場合はページ単位のBookmark ON/OFFを取得できるようになっている。
が。実際のそのテストケースを作ろうとして。
・・・これ、要らなくね?
現実問題として、一つのStoryの中にBookmark ON/OFFが混ざることはあり得るのか?例えXhwlay側でサポートするとしても、本当にそんなStoryを作る場面があるのか?当初予定としては、例えばヘルプ画面ポップアップのようなものを想定していたが、それにしたってBookmarkOFFのヘルプ画面専用のstoryを作るのが普通じゃないか?
何よりも、BookmarkON/OFFの混ざったStoryって、激しくメンテナンス性が悪くないか?絶対に、あとあとFlowが追えなくなる。
というわけで、Xhwlay_Runnerレベルではもう、ページ単位のBookmark ON/OFFはサポートしない。どうしてもやりたければ、Xhwaly_Runnerをextendsして、コアを好きなように書き換えて下さい。という感じ。
まあ、Config側のIFは変更しない。Configの機能としては、純粋にまあ、あっても良いかなという感じなので。
そんなところ。
そしてようやく、な感じ。PartialBookmarkの見送りに助けられた。
小さな変更点として、Page/Event/Barrier/Guardの各種callbackを取得する為の _getCallback($params) 内で、
define('XHWLAY_RUNNER_HOOK_CLASSLOAD', "xhwlay_runner_classload");
で定義されるHOOKを呼ぶよう、修正した。Testには盛りこみ済。
一応現状は、デフォルトの _getCallback()は
"user_function" > "class" & "method"
の優先度でcallbackの有効性を判断している。classloadのHookを仕込むことにより、これらのパラメータに応じて動的にファイルをrequireできるようになる。
まあ、PokoXにあった
$POKOX_MODULE_AUTOLOAD_PATH
を好き勝手に実装してもらう為のマージン。
最近はPEAR形式のクラス名やディレクトリ構造を取ったりもするので、環境によって変わるだろうし・・・。
さて、これでベースコアは一応まとまった。普通のsessionベースでのサンプルと、ログイン/ログアウト込みのサンプルの準備に取りかかろう。
sessionを使わないのは・・・まあ、一応準備するか・・・。多分、あり得ないんだけど。だってBCID(Bookmark Container ID)自身がsessionIDになってしまうから。そうなると。・・・まあ、それはそれで無理矢理Cookie経由でやりとりさせて・・・って、それじゃsessionを使ってるのと変わらないし。