Noon::Gadget::Include
package Gadget::Include;

# News::Page::Stories から呼ばれます。
# News::Page::Stories は build するとき、
# タグの置換を Gadget::Include へ delegate します。
# タグの中に Gadget::Include がコンポジットしてるオブジェクトを書きます。

# HTML ページにコードを移動するということは Noon の基本的概念に反します。
# ページを作成するためだけのロジックであってもページに書くべきではありません。
# コードはちゃんとコードとして書くべきです。
# コードの中に HTML を含めるように書けばよいのです。
# ビジネスロジックはモジュールとして書かれ、共有されるべきです。
# ビジネスロジックとは、インターフェースやデータ管理などを切り離した、
# アプリケーションのコアになる要素です。

# モジュールがどんどん整備されていくと、
# Embperl, Mason のような複雑なテンプレートソリューションのモデルは、
# 結局、CGI.pm に見られるようなものに落ち着くことになります。

# Noon の基本的概念では
# ページにコンポーネントオブジェクトを置くだけで済ませます。
# オブジェクトは自律的な存在です。
# オブジェクトは自らの振る舞いと見栄えに責任を持っています。
# したがってコンポーネントオブジェクトはロジックとデータと HTML を含包します。
# コンポーネントの再利用、汎用性を考えれば、
# コンポーネントはコードとして書かれるべきです。
# HTML として書かれるべきではありません。
# したがって、Mason のようなアプローチは、最初、魅力的に見えても、
# プロジェクトが発展、洗練されていくにしたがって、足枷になっていきます。
# Mason コンポーネントとして書かれたロジックは、
# 再利用できず、破棄されてしまうことになります。
# Mason や PHP のようなソリューションを積極的に導入するメリットはありません。
# モジュールを整備することに時間を使うべきです。
Noon::Gadget::Item
package Gadget::Item;

# Item クラスをコレクションするクラス (MVC でいえば controller)
# (Collection::Item という名前でもいい)
# おもに Gadget::Include に aggregate されて仕事をする
# build メソッドを持っているので component とも言える。
# build 関連は ItemBuilder に delegate する

# Aws
# |  ProductP
# |  |
# ItemP  ItemBuilder
# |      |
# Gadget::Item
# |
# Gadget::Include
# |  |  |
# |  |  News::Page::Stories
# |  blosxom/plugin/item
# item.pl

topic: perl
first posted: 2011-06-16 11:56:18
last modified: 2011-06-16 19:22:09