Woolpack の特徴。
  Woolpack の特徴を以下に示す。

  特徴 | 理由 | 利点 | 概念上・実装上の欠点 | 該当モジュール
  --- | --- | --- | --- | ---
  インタープリタ デザインパターンを使用する。 | 利点に同じ。 | 処理を共通化・部品化することが創発される。特にビューの加工や値検証など HTTP リクエストや業務をまたがった横断的な部品を定義することができる。 | Context 役で直接管理するプロパティを選定する難易度が高い。 | config / dom / el / html / text / utils / validator の各パッケージ
  なるべく設定に XML を使用しない。コンストラクタのパラメータで設定する。 | 柔軟性を確保するスキーマ設計と XML をインスタンスツリーに変換する設計の難易度が高い。シリアル化(サーバ間で設定を通信するなど)を必要としない。 | 設定の構造化が維持されるため設定の見える化が維持される。 設定の分割が容易。 部品化が創発される。 Java エディタ以外のエディタ(Eclipse の設定ファイル編集専用プラグインなど)必要としない。 Java の場合は全ての機能が Java の API として表現されてるため、API のリファレンスが Javadoc のみである。 Java の静的型検証により設定の品質が維持される。 | Java 言語は new 宣言の引数に変数名を付けることができないため可読性が悪い。動作定義の動的変更機能を具備しない。 ユーザのソースコードに文字列が直接指定する記述になるため、文字列を ResourceBundle 化するなど一部のコーディング規約を遵守することができない(遵守すると可読性が低下する)。 Java 言語は静的型の言語であるため、型宣言の記述が多くなる。 | API 全体
  コンストラクタツリーとしてユーザが設定を定義(構文木をパース)する。 | 利点に同じ。 | 設定が構造化される。 | 複雑になると丸括弧の入れ子が増えるため可読性が悪い。 | config / dom / el / html / text / utils / validator の各パッケージ
  HTML 雛型と変換(値の注入)定義を分離する。 | HTML 雛型と変換定義を疎結合化。Mayaa にインスパイアされた。 | HTML 雛型をまたがった変換定義を共通化/部品化することが創発される。 | 特定の HTML 雛型に固有の処理を記述する柔軟性がない。 | dom / html の各パッケージ
  HTML での入力値・妥当性チェック・モデル層のコンポーネントの間で、プロパティ名により値を自動バインドする。 | 利点に同じ。 | HTML での入力値・妥当性チェック・モデル層のコンポーネントでプロパティ名を統一することにより、個別に値をバインドする定義が不要になる。 | 識別子の値を個別に変換してバインドする仕掛けを用意していない。 | validator パッケージ, AutoUpdate, ActionInvoker
  Struts の Tiles に相当する機能として HTML フレームを HTML テーブルに変換する機能を具備する。 | 利点に同じ。 | HTML で作成したレイアウトをそのまま利用することができる。 | target 属性値の判定機能を具備しない。コンストラクタツリーで作用対象の HTML を指定する必要がある。XHTML に対応していない。 | Frame2Table
  Context 役の各プロパティを J2SE の API に限定している。 | 利点に同じ。 | JUnit によるテストの容易性が維持される。フレームワーク設計の抽象化が維持される。Servlet API に依存する部品が局所化される。 | クライアント情報(Locale や OS/ブラウザ名など)による処理の分岐をするためにはコレクションフレームワークを媒介するか ThreadLocal を使用する必要がある。 | DomContext
  コンテキスト役へのアクセスに OGNL を利用することが可能。 | 利点に同じ。 | 動的型検証のため記述が容易。 | OGNL 文を Java ソースの String 値として定義するため、エスケープ文字(バックスラッシュ)の定義の可読性が悪い。 | API 全体
  Java 言語の final キーワードを多用する。 | リエントラントが静的に検証される。 | 動点固定法の効果により設計上アイデアが創発される。リエントラントの見える化が維持される。クロージャが使用できる。 | 動的に設定を更新することができない。ソースコード上の final 宣言がくどい。参照型変数のコピーをとる実装を行っていない。 | API 全体
  Generics を多用する。 | 利点に同じ。 | ソースの可読性が維持される。 | 1.4 以前の JSE では動作しない。 | API 全体
  dom / html の各パッケージのクラス名が名詞になっていない。 | Expression 役が LISP の関数と対応づけられる、また Expression 役は文法規則を表すことが多いため、名詞にする効果が弱いと判断した。 | コンストラクタツリーが読みやすい。 | 一般的なクラス名の命名規則に従っていない。 | dom / html の各パッケージ
  Woolpack が利用するライブラリで発生した RuntimeException のサブクラスでない例外は全て RuntimeException でラップして投げる。 | Woolpack がまだ例外設計をする段階に達していない。 | 部品の設計が単純化されている。 | 呼び出し元で Throwable#getCause() を解析する必要がある。 | API 全体
  Context　役に　Prototype　デザインパターンを適用することにより、変数スコープを表現している。 | Expression　役のコンストラクタツリーで変数スコープを実現する。 | Expression　役の作用範囲を制御することができる。 | 言語の変数スコープ程の柔軟性を持たない。 | DomContext, ConfigContext, ValidatorContext
  フレームワーク自体はログを出力しない。 | Woolpack　がまだログ設計をする段階に達していない。 | 部品の設計が単純化されている。 | デバッグ用のデータが不足する可能性がある。 | API　全体