dolem0.12.0のリリース
Read More
dolemのVerUP。
今回のでdolemのVerは0.12.0となった。
■dolem:ダウンロードページ
http://dolem.jp/?m=download
前回Ver.0.11.0ではBaseManagerクラスの修正が主だったが、今回のVer.0.12.0ではそれと同じ修正をBaseModelクラスにも適用した。
あ、ついでにBaseManagerクラスのcount()のバグを修正した。
これでBaseManagerクラスのクラスプロパティ操作関数と、BaseModelクラスのキャリー操作関数は関数が名前と挙動が完全に統一された。
※ただしBaseModelクラスにはセッションへの保存・復元機能はない。
なお関数名が変更されたわけではないので過去のVerのものへの影響はない。
以下はBaseManagerクラスとBaseModelクラスの共通するメンバ関数の一覧。
■共通するメンバ関数一覧。
BaseModelクラスには新たにisScalar()が実装された。
これはBaseManagerクラスにVer.0.11.0で追加されたものと同じもの。
同じように逆輸入でBaseManagerクラスにkeyExists()が実装された。
なおBaseModelクラスのreset()は削除予定とする。
これはclear()が正しく実装できたことによりその必要性を感じなくなったため。
というかまったく使いどころがなかった。
このような無駄なメンバがあると理解する時間が余計に伸びるだけなので消す方向で動く。
あとforward()というメンバ関数の引数を可変長引数に変更した。
これにより複数の関数名が指定できるようになった。
もちろん以前の記述も同じように使えるのでこれによる影響はない。
forward()はモデルファイルの通常ワークフローを変更するために利用する。
以下にforward()の使い方例をいくつか載せておく。
■forward(): ワークフローの変更
これはVer.0.1.0から可能だった書き方。
通常ワークフローならばinit()→main()→disp()となるが、
ある条件の時のみ、
init()→main()→sub()→disp()という動きとなる。
■forward(): ワークフローの変更その2
こちらが今回のVer.0.12.0から新たに使えるようになった動き。
通常ワークフローならばinit()→main()→disp()となるが、
ある条件の時のみ、
init()→main2()→disp2()という動きとなる。
$this->forward('main2', 'disp2');の直後でreturn false;をしないとdisp2()の実行後にmain()->disp()が実行されるので注意が必要となる。
ただし現時点では通常ワークフローの時にmobileと判断された場合、画面出力する文字エンコードは自動的にSJIS-winにコンバートされるようになっている。
このため上記のような独自のdisp2()を作った場合この処理が走らない。なので別途書かなくてはならない。
ゆえにワークフローを書き換えてしまうようなことをすべきでない。
今回の可変長引数の実装で通常のワークフローとは大きく離れた独立性の高い動きが実装可能となったがこれは可読性の面からも多用するのはできるだけ避けたい。
というか実装しているもののまだ変更がありそうなのでできるだけ使って欲しくないというのが本音。
--
ここで少し将来的な話をしてみる。
ここまで注意が必要なforward()を既にBaseModelに実装しているのかというのにはちょっとした理由がある。
現在boot.phpでは受信コマンドとして'c, m, e'を受け付けることができる。
※vコマンドは現時点では実質的に許可していない。
これに加え将来的にはfコマンドも有効にしたいと考えている。
これはあくまで構想レベルだが。
そのためforward()を先行して実装してたというわけ。
具体的にはURLにmやeなどと同じようにfキーが指定できるようし、fキーで指定した関数をワークフローとして実行させる、というもの。
ただしこの時どの関数でもURLから指定できては困るため、URLからのアクセスを許可するか否かを判断するフラグのようなものを別途定義させる必要が出てくる。
そのフラグがOnになっているもののみURLからfキー指定で叩けるというような感じ。
ex) ttp://xirasaya.com/?m=index&f=init2
この許可フラグを実装するための方法を考えてみた。
案1:
BaseModelクラスのメンバ変数に$original_workflow_function(仮)なるものを持たせる。
派生させたモデルファイル側でこのメンバ変数を上書きさせる形でここにURLからの実行を許可する関数名を定義すると。
こうすればプログラマに一目でURLから叩くfunctionがあるんだなと判断させることができる。
■案1の実装例
上記の案の場合?m=index&f=init2を叩くと最初からinit2()→main2()→disp2()が動く、という感じ。
$original_workflow_functionは二次元配列で複数のワークフローを指定できるようにしてもよい。
その場合は関数がかぶったときどう処理させるかを考えなくてはならない。
URLからのアクセスを許可する関数は、配列の一番最初の要素のみに限定するという仕様とかどうだろう。
つまり上記の例だと/?m=index&f=init2のみ許可することになるかな。
…と、ここまで書いてみたもののやっぱちょっと複雑すぎんなあ。
正直なところmodelファイルにinit()、main()、disp()以外に余計なものを極力定義させたくない。
もちろんプログラマがmodelファイルのクラスに独自のメンバ関数を追加するのは一向にかまわんのだが、
オリジナルワークフローのためのfunctionや、それを許可するメンバ変数とかはっきりいって邪魔くせえ。
そもそももしこれを実装した場合モバイル判定して文字エンコードを変更するという処理はどこでやればいいのか。
さらに何かしらのメンバ変数を用意するのか?
そんなの美しくない。
とまあ未だにfコマンドを実装できてないのはこの辺が解決できてないから。
独立したワークフローを実装したいのなら別のmodelファイルを用意するだけで解決するしな。
今回のでdolemのVerは0.12.0となった。
■dolem:ダウンロードページ
http://dolem.jp/?m=download
前回Ver.0.11.0ではBaseManagerクラスの修正が主だったが、今回のVer.0.12.0ではそれと同じ修正をBaseModelクラスにも適用した。
あ、ついでにBaseManagerクラスのcount()のバグを修正した。
これでBaseManagerクラスのクラスプロパティ操作関数と、BaseModelクラスのキャリー操作関数は関数が名前と挙動が完全に統一された。
※ただしBaseModelクラスにはセッションへの保存・復元機能はない。
なお関数名が変更されたわけではないので過去のVerのものへの影響はない。
以下はBaseManagerクラスとBaseModelクラスの共通するメンバ関数の一覧。
■共通するメンバ関数一覧。
set() get() get_h() clear() remove() isScalar() keyExists()
BaseModelクラスには新たにisScalar()が実装された。
これはBaseManagerクラスにVer.0.11.0で追加されたものと同じもの。
同じように逆輸入でBaseManagerクラスにkeyExists()が実装された。
なおBaseModelクラスのreset()は削除予定とする。
これはclear()が正しく実装できたことによりその必要性を感じなくなったため。
というかまったく使いどころがなかった。
このような無駄なメンバがあると理解する時間が余計に伸びるだけなので消す方向で動く。
あとforward()というメンバ関数の引数を可変長引数に変更した。
これにより複数の関数名が指定できるようになった。
もちろん以前の記述も同じように使えるのでこれによる影響はない。
forward()はモデルファイルの通常ワークフローを変更するために利用する。
以下にforward()の使い方例をいくつか載せておく。
■forward(): ワークフローの変更
<?php // 略 class template extends BaseModel { function init() { return true; }// end function function main() { if({条件}) return $this->forward('sub'); return true; }// end function function sub() { return true; }// end function function disp() { return true; }// end function }// end class ?>
これはVer.0.1.0から可能だった書き方。
通常ワークフローならばinit()→main()→disp()となるが、
ある条件の時のみ、
init()→main()→sub()→disp()という動きとなる。
■forward(): ワークフローの変更その2
<?php // 略 class template extends BaseMode { function init() { if({条件}) { $this->forward('main2', 'disp2'); return false; }// end if return true; }// end function function main() { return true; }// end function function disp() { return true; }// end function function main2() { return true; }// end function function disp2 () { return true; }// end function }// end class ?>
こちらが今回のVer.0.12.0から新たに使えるようになった動き。
通常ワークフローならばinit()→main()→disp()となるが、
ある条件の時のみ、
init()→main2()→disp2()という動きとなる。
$this->forward('main2', 'disp2');の直後でreturn false;をしないとdisp2()の実行後にmain()->disp()が実行されるので注意が必要となる。
ただし現時点では通常ワークフローの時にmobileと判断された場合、画面出力する文字エンコードは自動的にSJIS-winにコンバートされるようになっている。
このため上記のような独自のdisp2()を作った場合この処理が走らない。なので別途書かなくてはならない。
ゆえにワークフローを書き換えてしまうようなことをすべきでない。
今回の可変長引数の実装で通常のワークフローとは大きく離れた独立性の高い動きが実装可能となったがこれは可読性の面からも多用するのはできるだけ避けたい。
というか実装しているもののまだ変更がありそうなのでできるだけ使って欲しくないというのが本音。
--
ここで少し将来的な話をしてみる。
ここまで注意が必要なforward()を既にBaseModelに実装しているのかというのにはちょっとした理由がある。
現在boot.phpでは受信コマンドとして'c, m, e'を受け付けることができる。
※vコマンドは現時点では実質的に許可していない。
これに加え将来的にはfコマンドも有効にしたいと考えている。
これはあくまで構想レベルだが。
そのためforward()を先行して実装してたというわけ。
具体的にはURLにmやeなどと同じようにfキーが指定できるようし、fキーで指定した関数をワークフローとして実行させる、というもの。
ただしこの時どの関数でもURLから指定できては困るため、URLからのアクセスを許可するか否かを判断するフラグのようなものを別途定義させる必要が出てくる。
そのフラグがOnになっているもののみURLからfキー指定で叩けるというような感じ。
ex) ttp://xirasaya.com/?m=index&f=init2
この許可フラグを実装するための方法を考えてみた。
案1:
BaseModelクラスのメンバ変数に$original_workflow_function(仮)なるものを持たせる。
派生させたモデルファイル側でこのメンバ変数を上書きさせる形でここにURLからの実行を許可する関数名を定義すると。
こうすればプログラマに一目でURLから叩くfunctionがあるんだなと判断させることができる。
■案1の実装例
<?php // 略 class template extends BaseModel { var $original_workflow_function = array('init2', 'main2', 'disp2'); function init() { return true; }// end function function main() { return true; }// end function function disp() { return true; }// end function function init2() { return true; }// end function function main2() { return true; }// end function function disp2() { return true; }// end function }// end class
上記の案の場合?m=index&f=init2を叩くと最初からinit2()→main2()→disp2()が動く、という感じ。
$original_workflow_functionは二次元配列で複数のワークフローを指定できるようにしてもよい。
その場合は関数がかぶったときどう処理させるかを考えなくてはならない。
URLからのアクセスを許可する関数は、配列の一番最初の要素のみに限定するという仕様とかどうだろう。
つまり上記の例だと/?m=index&f=init2のみ許可することになるかな。
…と、ここまで書いてみたもののやっぱちょっと複雑すぎんなあ。
正直なところmodelファイルにinit()、main()、disp()以外に余計なものを極力定義させたくない。
もちろんプログラマがmodelファイルのクラスに独自のメンバ関数を追加するのは一向にかまわんのだが、
オリジナルワークフローのためのfunctionや、それを許可するメンバ変数とかはっきりいって邪魔くせえ。
そもそももしこれを実装した場合モバイル判定して文字エンコードを変更するという処理はどこでやればいいのか。
さらに何かしらのメンバ変数を用意するのか?
そんなの美しくない。
とまあ未だにfコマンドを実装できてないのはこの辺が解決できてないから。
独立したワークフローを実装したいのなら別のmodelファイルを用意するだけで解決するしな。
着実にパワーアップしていますね。
[f]のことをそんな風に考えてたなんて。
さすが師匠♪
coreFWのダメだったとことか教えてね。
dolemにも反映させたいから
ダメなとこを私みたいのが言える立場じゃないですが、
気付いたことがあれば報告しますね!