アクションベースのJavaフレームワークを使用したWebアプリケーションを開発する原則は何ですか？

Question

バックグラウンド

Javaとの新しいWebアプリケーションを開発します。それはそれほど大きくないか、それほど複雑ではなく、「公式に」始まるまで十分な時間があります。

JSF/フェイスラット開発の背景（約半年）があります。また、JSP+JSTLにはいくつかの期限があります。

自己教育目的で（そして最良の解決策を見つけるためにも）、アクションベースのフレームワークの1つで新しいプロジェクトをプロトタイプしたいと思います。実際、私はスプリングMVCとストライプのどちらかを選択します。

問題

（JSFと比較して）アクションベースのフレームワークについて正しい印象を得るために、（より大きなまたはそれほどではない）正しく使用することを確認したいと思います。

そこで、ここでは（少なくとも私にとっては）最も頻繁なタスクをいくつかリストし、JSFでそれらをどのように解決するかを説明します。アクションベースのフレームワークでそれらをどのように解決すべきかを知りたい（または、具体的なタスクに違いがある場合は、スプリングMVCとストライプで別々に）。

1. コンテンツのレンダリング: ：標準のJSFライブラリ（CoreおよびHTML）またはサードパーティLibs（Richfacesなど）からすぐに使用できるコンポーネントを適用できます。簡単なコンポーネントを組み合わせることができ、標準コンポーネントに基づいた独自のコンポーネントを簡単に作成できます。
2. 正しい形式でデータ（プリミティブタイプまたは参照タイプ）をレンダリングする: ：各コンポーネントは、aを指定できます コンバータ 両方の方法でデータを変換する（レンダリングおよびサーバーに送信するため）。コンバーターは、いつものように、2つの小さな方法を持つ単純なクラスです。
3. サイトナビゲーション: ：のセットを指定します ナビゲーションケース facesconfig.xml。次に、1つ以上のナビゲーションケースに一致するはずのリンク（またはボタン）のアクションアトリブを指定します。最高の試合はJSFによって選択されます。
4. フローの実装（たとえばマルチフォームウィザード）: ：JSF 1.2を使用しているので、使用しています アパッチオーケストラ フロー（会話）スコープの場合。
5. フォーム処理: ：ある程度の範囲で、かなり標準的なJava-Bean（JSFの用語で豆を裏打ちする）があります。私はこの豆のプロパティにフィールドをフォームします。すべてがうまくいかない場合（例外と検証が渡されません）、これらのプロパティはすべて、フォームフィールドの値で設定されます。その後、1つのメソッドを呼び出すことができます（ボタンで指定されています アクション 属性）次の画面に移動するために私のナビゲーションケースの1つが大いに必要なロジックと返品文字列を実行します。
6. フォーム検証: ：カスタムバリーターを作成し（または既存から選択して）、ほぼ各コンポーネントに追加できます。サードパーティライブラリには、カスタムAjax-Validatorsのセットがあります。標準的なバリデーターは、ページが送信された後にのみ機能します。実際、私はJSFの検証がどのように機能するかは好きではありません。そこに魔法が多すぎます。多くの標準的なコンポーネント（またはすべて）には事前定義された検証があり、それを無効にすることは不可能です（おそらく常にではありませんが、私はそれで多くの問題を満たしました）。
7. ajaxサポート: ：多くのサードパーティライブラリ（MyFaces、IceFaces、OpenFaces、AnotherPrefixFacesなど）は強力なAJAXサポートを備えており、非常にうまく機能します。問題になるまで。そこにも魔法が多すぎます。動作しない場合は機能させることは非常に困難ですが、マニュアルに記載されているように正しく行っています。
8. ユーザーフレンドリーなURL: 人々は言います そのためのライブラリが存在すること。そして、それはできます フィルター付き 同じように。しかし、私は試したことがありません。最初の外観には複雑すぎるようです。

これらのアイテム（またはそれらの一部）をアクションベースのフレームワークでどのように実行できるかを説明してくれてありがとう。

Answer 1

私はそれについて答えるために最善を尽くします ストライプ. 。私は過去にStrutsとJSFを使用しましたが、最近ではありませんでしたので、せいぜい曖昧な概念とそれらについての感情を持っています。

私たちはストライプで親密に馴染みのあるものであり、今ではほとんどすべてのためにそれを使用し、本当に楽しんでいます。飛び込むのは簡単で、複雑なシナリオの多くをサポートしていますが、それ以外では自由に作業することもできます。これは、独自のAjaxウィジェットを構築したり、別のシステムなどに話しかけたい場合に非常に重要です。

ストライプルートに行くと、i 絶対に 購入またはダウンロードをお勧めします 本. 。これは、ストライプに必要なものすべてのワンストップショップであり、実際にはStripersistの唯一のドキュメントです（本当に素晴らしい機能ですが、Webドキュメントはありません）。

---

コンテンツのレンダリング：標準のJSFライブラリ（CoreおよびHTML）またはサードパーティLibs（Richfacesなど）からすぐに使用できるコンポーネントを適用できます。簡単なコンポーネントを組み合わせることができ、標準コンポーネントに基づいた独自のコンポーネントを簡単に作成できます。

これは似ています。 Core、HTML、FMTなど、および見つけたカスタムタグ、Inc。ディスプレイ：タグ、パックタグ、および独自の作成を作成します。ただし、明らかにコンポーネントレベルで取引していません。ページにあるもの /サーバーに送信されるものを決定するタグを扱います。

正しい形式でデータ（プリミティブタイプまたは参照タイプ）をレンダリングする：各コンポーネントは、両方の方法でデータを変換するためのコンバーターを指定することを可能にします（サーバーにレンダリングおよび送信するため）。コンバーターは、いつものように、2つの小さな方法を持つ単純なクラスです。

Stripesには多くの組み込みコンバーターがあり、より複雑なデータ型のためにカスタムコンバーターを簡単に作成できます。 Stripesは、非常に複雑なデータ構造をサポートして、手間がかからずにマッピングされます。と組み合わせ ストライパー師, たとえば、モデルオブジェクトをActionBeanに直接配置し、フォームにいくつかのフィールドを配置できます。StriperSistは、モデルをDB（PKに基づいて）から水分補給し、フィールドを更新することができます。フォーム-ActionBeanで私にコントロールをリリースする前にすべて。

サイトナビゲーション：FacesConfig.xmlでナビゲーションケースのセットを指定します。次に、1つ以上のナビゲーションケースに一致するはずのリンク（またはボタン）のアクションアトリブを指定します。最高の試合はJSFによって選択されます。

ストライプのナビゲーションは、最初はActionBeansの名前に基づいています。 XMLはありません。さらに、 きれいなURL Stripes 1.5のActionBeanレベルでの注釈です。そのため、 @UrlBinding("/{$event}/{model}") どこ /view/5 あなたを「view「ID/PKが5のモデルオブジェクトのイベントハンドラー。

Flowの実装（たとえばMultiform Wizards）：JSF 1.2を使用しているので、Flow（会話）スコープにApache Orchestraを使用しています。

私は会話の範囲の概念に漠然と精通しているだけですが、ストライプは持っています ウィザードフォーム 機能性ですが、私はそれを使用しておらず、実際にそれを拡張することはできません。同様のアイデアだと思います。

フォーム処理：いくつかの範囲で、かなり標準的なJava-Bean（JSF用語でBeanをバッキングする）があります。私はこの豆のプロパティにフィールドをフォームします。すべてがうまくいかない場合（例外と検証が渡されません）、これらのプロパティはすべて、フォームフィールドの値で設定されます。次に、1つのメソッド（ボタンのアクション属性で指定）を呼び出して、次の画面に移動するためにナビゲーションケースの1つが必要ないくつかのロジックを実行し、文字列を返すことができます。

劇的に違いはありません。 [Action] Beanのコンポーネントの代わりに、Javaまたはカスタムタイプができました。 ActionBeansは、リクエストごとに作成され、廃棄されます。これは素晴らしいことです。すべてのインスタンス変数がフォームのデータにマッピングされ、それを使用してから捨てて、Strutsのような同期の問題に対処する必要がないためです。データを使用して自分のことをした後、Stripesを使用すると、ForwardResolution（OKステータス）、リダイレクト、またはストリーミング（JSON、ファイルなど）を送信できます。リダイレクトアフターポストパターンは、 フラッシュスコープ （ページの3/4）。

フォーム検証：カスタムバリエーターを作成（または既存から選択）して、ほぼ各コンポーネントに追加できます。サードパーティライブラリには、カスタムAjax-Validatorsのセットがあります。標準的なバリデーターは、ページが送信された後にのみ機能します。実際、私はJSFの検証がどのように機能するかは好きではありません。そこに魔法が多すぎます。多くの標準的なコンポーネント（またはすべて）には事前定義された検証があり、それを無効にすることは不可能です（おそらく常にではありませんが、私はそれで多くの問題を満たしました）。

Stripesは、ActionBeanのインスタンス変数での注釈の検証を可能にします。デフォルト、必須、maxlengthなどを許可するか、いつでも独自のデフォルトを作成できます。デフォルトは簡単に追加でき、柔軟性がありますが、常に完全にカスタマイズされたものを作る機能が常にあります。

AJAXサポート：多くの第3パーティライブラリ（MyFaces、Icefaces、OpenFaces、AnotherPrefixFacesなど）は強力なAJAXサポートを備えており、非常にうまく機能します。問題になるまで。そこにも魔法が多すぎます。動作しない場合は機能させることは非常に困難ですが、マニュアルに記載されているように正しく行っています。

これは、JSFのやり方の私の大きな問題でした。あなたがウィジェットを正しく取得したとしても、あなたはまだそのウィジェットにこだわっています。ストライプを使用すると、最新かつ最高のjQueryが提供するものは何でも使用できます。また、サーバーに正しい取得または投稿を送信する限り、Stripesはそれをどうするかを知っており、JSONを簡単に送り返すことができます。コンポーネントフレームワークは、Ajaxが難しい場合、数年前にはるかに良くニッチに適合すると思いますが、JQは今ではとても簡単にしています。

ユーザーフレンドリーなURL：人々は、そのためのライブラリが存在すると言います。また、フィルターでも行うことができます。しかし、私は試したことがありません。最初の外観には複雑すぎるようです。

@urlbinding, 、それはそれと同じくらい簡単です。

Answer 2

私の答えはあなたが聞きたいものではありません：コンポーネントフレームワークからアクションフレームワークに切り替えないでください

私は長年のアクションフレームワーク開発の後、逆の方法を切り替えましたが、決して戻ることはありません。

あなたが言及した8つのユースケースのうち、アクションフレームワークが明らかに優れている場所である1つだけが思い浮かびます。それがURL設計 /フレンドリーなURLです。コンポーネントフレームワークでも行うことができますが、アクションフレームワークがはるかに簡単です（特に、アクションビーンにURLで注釈を付けたストライプで）。

ウィケットを試すことをお勧めします。学ぶのは非常に簡単です（JSFよりもはるかに簡単）。多くの既存のコンポーネントも再利用できます。