システム開発ツールCejuno 

Cejuno Frameworkの根幹「Workflowモデル」 (3/3)

WorkProcessの切り替え

WorkProcessは、HTMLフォームから送信される「apn」によって切り替わります。

このプロセス遷移によってWorkflow全体が構成され、一連の処理が順に実行されることで、最終的な目標（ここでは会員情報登録）が達成されます。これがWorkflowモデルにおける基本的な動作となります。

もちろん、この基本動作に加えて、WorkProcessを飛び越えて遷移したり、別のWorkflowへ移動したりと、さまざまな制御を行うことも可能です。

ProcessControllerによるコントロール

WorkProcessの前段で“ページの文脈”を正しく整える制御層としてProcessControllerを定義することができます。（省略可能）

通常、Cejuno Frameworkでは初回アクセス時に「apn」が空であれば、Workflowコンフィグに定義された最初のWorkProcessがロードされます。

しかし実際の業務では、「ただ先頭のプロセスを実行する」だけでは成り立ちません。

• ログインしていない場合はログインページへ強制遷移
• 購入フローなら、OrderModel が保持する状態に応じて適切なプロセスへ遷移
• 前提条件を満たさないアクセスを別ページへ誘導
• 特定のEntityやセッション状態によって開始プロセスを変更

こうした「ページに入る前の文脈判断」を行うのがProcessControllerです。

デフォルトで多数のコントローラが用意されていますが、基底クラスを継承するだけで、各プロジェクト独自のビジネスロジックに最適化したコントローラを自由に作ることができます。

つまり、ProcessControllerは“Workflowが動き始める前に、アプリ全体の整合性を担保する守護神”として機能する、Cejuno Frameworkの重要な制御ポイントです。

プロジェクト共通のモデル（Model）

Workflowを跨いで状態を保持する“長寿命オブジェクト”

多くのWebフレームワークでは、画面遷移を跨いで「共通ロジックや共通状態」を扱いたい場合…

• 毎回ユーティリティクラスを生成し直す
• 毎回必要な値を初期化し直す
• 状態保持のためにセッションやグローバルを多用する

といった煩雑さがどうしても生じます。

Cejuno Frameworkではこの問題を “共通モデルオブジェクト” によって完全に解消しています。

WorkflowコンフィグのController内でModelを宣言するとCejuno FrameworkはController生成時にこのモデルを自動的に初期化し、さらにProcessContextに紐づけて永続的に保持 します。

WorkProcessやTaskを跨いで同じモデルを参照できるため、

• 決済フロー中の注文情報
• マルチステップ入力のドラフトデータ
• ログインユーザーの操作コンテキスト

といった “継続して保持すべき情報” を美しい形で扱えます。

実際の取得方法は非常にシンプルで、

$model = &$this -> mManager -> getModel("Order");

OrderModelというクラス名を気にする必要すらなく、「Order」という名前だけでアクセスできます。
もちろん、$this -> mManagerの正体はこの例ではProjectControllerです。

そして興味深いのは、Controllerは“Manager”インターフェースを実装したオブジェクトとして扱われ、WorkflowManagerからはManagerインターフェースが保証するメソッドだけ が呼び出せる。

という安全志向の設計になっている点です。

※PHPは厳密なインターフェース制約が弱いため“概念的”ではありますが、Cejuno Framework思想としての安全設計には大きな意味があります。

Cejunoの活用

以上がWorkflowモデル基本動作の概要解説となります。

Cejuno Frameworkだけでも製造作業を大幅に削減できますが、上位開発ツールであるCejunoを利用することで、Frameworkで必要となるソースコードや各種設定ファイルを、入力フォームを通じて自動的に作成・編集することができます。

そのため、PHPやHTMLといったプログラム言語を知らなくてもWebシステムの開発が可能となり、より簡単かつ効率的にシステム構築を行うことができます。

ぜひCejunoを活用し、開発コストの削減と生産性の向上を実現してください。

ページナビ