目次
Workflowモデル
Cejuno Frameworkの基本モデルは、従来のMVCモデルに加えて独自の概念でありフレームワークの根幹となるWorkflowモデルを採用しています。
Workflowモデルでは、一連の処理全体をWorkflow、ページ切り替えごとの処理単位をWorkProcess、ページ内で実行される個々の動作をTaskと定義します。
これらの処理構造と流れをXMLで定義したコンフィグXML(以降、Workflowコンフィグと呼びます)をロードし、適切なクラス群を正しい順序で呼び出して処理を実行することで、プログラム動作を自動化しています。
ここでは具体例として、会員情報登録機能を題材にWorkflowモデルを解説します。
会員情報登録ページを「/member/regist.php」とした場合、その機能全体の処理の流れをWorkflowと捉えます。
会員登録の流れをシンプルに整理すると、入力画面、確認画面、登録処理(画面なし)、完了画面という4つの処理で構成され、これらがWorkProcessに相当します。
さらに各WorkProcessには、それぞれ実行すべき固有の処理が存在し、それらをTaskとして扱います。
1-1. Workflowモデル
例)会員情報登録処理の場合

「フレームワークを使っているのに、なぜ毎回ゼロからファイルを配置し、コードを書くのか?──Cejuno Frameworkはその前提を根本から覆します。」
既存のほとんどのフレームワークでは、MVCモデルにおけるControlとModel部分の処理を、開発者が自らコーディングする必要があります。画面遷移、入力チェック、登録処理など、そのほとんどを手作業で実装しなければならず、作業量は大きく、開発者の経験やスキルによって品質もばらつきが生じます。
しかし、Cejuno FrameworkのWorkflowモデルでは、このControl部分(WorkflowおよびWorkProcess)を自動化し、さらにModelに相当するTaskを細分化することで、Taskレベルの基本処理の多くも自動化されています。結果として、従来なら大量のコーディングが必要だった部分のほとんどが、Cejuno Frameworkでは“設定を記述するだけ”で実現できます。
例えば、会員情報に写真を追加したい場合でも、WorkProcess2とWorkProcess3のTask2~Task3の間に画像アップロード用のTaskを1つ追加するだけで機能を拡張できます。
また、画像アップロードを含むこれら多くのTask処理を行うModelクラスはあらかじめ用意されており、それらを制御するControlクラス、情報を表示するViewクラスも標準で提供されています。これにより、多くのケースではPHPもHTMLもほとんどコーディングする必要がありません。
ページ固有の特別な処理が必要な場合でも、その処理に近い既定のTaskクラスを継承して差分となる独自ロジックだけを記述すればよく、フレームワーク本体に手を加える必要はありません。
このように、あらゆるシステムで必要となる基本処理を行うクラス群は最初から揃っており、プロジェクト独自の要件については、Taskクラスの継承、プラグインの利用、または独自のUtilityクラスを追加することで簡単に組み込むことができ、必要に応じてこれらのクラスを自由に組み合わせて再利用できる構造になっています。
なお、図中にある「情報」は、Cejuno Frameworkにおける全ての処理で重要な役割を持つ情報保持オブジェクト(Entity)を指します。CPDK内ではEntityクラスとして定義され、個別特有の情報はXML(以降、Entityコンフィグと呼びます)により定義します。
