私は wicket を使用して簡単なアプリケーションを構築しようとしていますが、これまでのところ感銘を受けています。Component クラスを利用して、ユーザー入力またはモデルに基づいてページ上の要素の動作を決定しています。コンポーネント モデルは JSF と似ていますが、ウィケットのライフサイクルの方が管理しやすいと思います。
私が理解できなかったのは、ページに記載されているすべての wicket:id に対して、特に子のないものに対して、すべてのコンポーネントをツリーに追加する必要があることです。ツリーがマークアップ内ですでにある程度定義されている場合、Java コードでツリーを構築する必要があるのは面倒です。私は何が欠けていますか？
編集
私はおそらく例を挙げるべきです。場合によっては変更できるようにしたい入力ボックスのラベルがあります。95% の確率で、マークアップのラベルに使用するテキストと属性は問題ありません。
簡単な答え：はい、追加する必要があります。
長い答え：これを行うためのカスタムコードを作成することはできますが、努力する価値があるとは思えません。
JSFでは、非htmlタグを使用します。このタグには1つのコンポーネントタイプが関連付けられており、たとえば、h:inputTextクラスに対応しているHtmlInputTextため、インスタンス化するクラスがわかります。
wicket:idWicketでは、HTMLファイルには（いくつかの例外を除いて）HTMLタグのみが含まれ、マークアップに追加するマーク付きタグごとに具体的なコンポーネントをインスタンス化する必要が<span wicket:id='xyz'>ありLabelますFeedbackPanel。 、WebMarkupContainerまたはいくつかのカスタムコンポーネント。
JSFを使用すると、マークアップでWicketを使用して、Javaコードで実行します。つまり、コンポーネントツリーを構築し、コンポーネントをプロパティにバインドし、イベントを処理します。すべてを1つのファイルに保持し（テンプレートファイルごとにクラスを作成する必要はありません）、多くの短所があります（長所があると思う人もいますが、私は逸脱します）。
あなたのページは、何もしない単純なフォームではありません。入力を変換して検証し、送信を処理し、Ajaxを使用してコンポーネントを更新します。JSFを使用すると、（コンパイル不可能、タイプセーフ、ツールが不十分、リファクタリング不可能な）テンプレートでこれらすべてを実行し、式、構成タグ、および-gawdforbid-ビジネスロジックで肥大化させます。
Wicketがこれをサポートしている場合（そして、問題として、このアドオンを自分で構築するために必要な柔軟性があります）、多くの追加の注釈（特別な非標準のタグと属性）を追加する必要があります。マークアップ、インスタンス化するクラス、更新するモデル、実行する検証などを宣言し、フレームワークの2つの美しさ、クリーンなHTMLテンプレート、およびビジュアルとロジックの明確な分離を損ないます。
JSF（とにかくそれほど難しくはない）よりも肥大化を抑えながら、テンプレートでより多くのことを行おうとする1つのフレームワークは、ApacheTapestryです。しかし、そのチュートリアルに見られるように、テンプレートをコードにバインドするために、非標準のタグを使用し、任意の規則に従う必要があります（あなたはそれを好きかもしれませんが、これが事実である場合は、申し訳ありません： P）。
場合によっては変更できるようにしたい入力ボックスのラベルがあります。95% の確率で、マークアップのラベルに使用するテキストと属性は問題ありません。
ラベルのコンテンツをモデルでラップし、そのラベルをコンテナーに入れ、コンテナーを再描画することができます ( target.add(container);)。