Apache Wicketの短所は何ですか？
Apache Wicket の良い点についてはたくさん読みましたが、悪い点を見つけるのは難しいです。すべての問題に対して常に適切なソリューションであるフレームワークはないので、Wicketのデメリットは何であり、どのタイプのプロジェクトで使用しないのですか？
よくある質問ではないかもしれませんが、重要な質問だと思います。
Wicketは、いくつかのかなり確かなコーディング慣行を要求します。たとえば、IModelをコンポーネントに保存しても、それをコンポーネントのモデルとして使用しないと、自動的に切り離されず、セッションサイズが大きくなる可能性があります。この種の管理は、ほとんどの場合Javaユーザーが慣れているものではありません。
Wicketはアクティブで、頻繁に更新されます。これは良いことですが、新しいバージョンに更新するたびに、より良いコーディング方法に移行するために多くのリファクタリングを行う必要があることに気づきました（1.4導入されたジェネリック、1.4.x導入されたonConfigure（）、1.5にはいくつかの異なるリソース戦略があります）。繰り返しになりますが、すべてが良い更新であり、より良いコードに向かっていますが、2年前ではなく今すぐWicketに来る人々を羨ましく思います:)
上記の両方を組み合わせると、基本的な機能セットを通過すると、Wicketは実際のプログラミングスキルを想定しているように感じます。あなたが優れた開発者であれば、Wicketがあなたにできることを気に入るはずです（そしてコードはJavaDocにかなり文書化されています）。初心者の場合、深くなるとイライラするかもしれません。
また、Google App Engineで「動作」する一方で、その環境で快適に動作するのを妨げるいくつかの問題を発見しました。それは別の議論です。
私の免責事項は、私は他に何も使用していないため、おそらく他のフレームワークのほうが悪いことです。
現実の世界では、Wicketの開発速度は非常に遅いです。組立ラインで工場労働者のように使用する事前に準備されたコンポーネントがない場合、新しいパネルを作成できるようになるまで生産性が低下します。コードの複雑さが増し、記述しなければならないコード行が事実上2倍になるため、コードを読み取ることが困難になります。あなたはインターネットや本で些細なことをする方法を常に探しています。たとえば、単純なリセットボタンはHTMLの1行ですが、Wicketではこれを行う方法をグーグルで検索する必要があります。それは単純なことを難しくし、困難なことを不可能にします。
Wicketで作成された本当に複雑なUIはまだ見ていません。 Wicketでは、事前に用意されたコンポーネントで構成されるシンプルなUIのみが可能です。 Wicketで構築されたすべてのUIは、それがWicketで行われなかった場合、よりクリーンなコードベースを持っている可能性があり、Wicketをドロップすることでより適切にスケーリングされます。 Wicketは、Nice UIウィジェットとして何も購入しません。 WicketのjQuery UI実装でさえ、jQuery UIを直接使用するだけでは劣ります。
私の仕事で何万行ものWicketコードを読んだ後、Wicketコードは基本的にスパゲッティコードであると言えます。ジェネリックと匿名の内部クラスを使用した、汚くてエレガントで冗長なコードがWicketよりも好きな場合は、Wicketよりも便利です。ラインノイズの量が非常に多い。このため、コードベースの保守性が低下します。これは、欠陥のあるWicket AJAX実装を使用する場合に特に当てはまります。
いくつかの答えは、ウィケットをコンポーネントツリーを動的に作成できないと宣言しています。真剣に、私はあなたたちがそこで別の改札で作業していることを;）
まず、Wicketはコンポーネントベースであり、ランダムなHTMLジェネレータではありません。
実際には、動的コンポーネントツリーを取得するのはかなり簡単です：
コンポーネントを別のコンポーネントに置き換えたいですか？ Component.replaceWith（Component）を使用します（空のMarkupContainerと組み合わせて使用するとかなり便利です）。
動的に変化するパネルのリストが必要ですか？それらをリピーターに入れます。
コンポーネントを非表示にしますか？ Componente.setVisible（）を使用します
そして、これを行うためのより多くの方法。
したがって、動的コンポーネントツリーを実行できないと思う人は、いくつかの例を挙げてください。それらについてお話しさせていただきます。
（さらに柔軟にする必要がある場合は、さまざまなソースからWicketロードマークアップを作成できます。動的ツリーを構築するために行ったことはありませんが、データベースまたはネットワーク経由でマークアップを取得できるようにするためです）
私は改札が本当に便利だと思っていますが、これは私がこれまでに見つけた欠点です。
- 疎なドキュメント：素晴らしい記事と本がいくつかあるにもかかわらず、私は決定的改札ガイドをまだ見つけていません
- WicketのURLはデフォルトでは醜い
- HTMLレイアウトとJavaコードの両方で定義する必要があるため、コンポーネントツリーを動的に定義することはできません。
ここで私の答えを見てください：
確かに、私はそれらを利点として挙げましたが、誰かが反対を感じる理由が簡単にわかります。
Wicketで絶対に実行できないことは何もありませんが、従うべき特定の基本的な概念（このWordの使いすぎを嫌うので、私はそれを哲学とは呼びません）があります。その概念から離れれば離れるほど、それをウィケットにシューホーンするのが難しくなります。
Apache Wicketに関する私の主な問題は、優れたオンライン参照資料がないことです。私は選択ボックスのような単純なものの例をGoogleで広範囲に検索しましたが、選択ボックスを機能させるだけでなく、なぜそのようにしているかを理解するのに役立つ何かを見つけるのが非常に困難でした。また、私はたくさん検索しましたが、Wicketアプリケーションを構築する方法の主要な概念の適切な基本的な概要が見つかりませんでした。
この時代では、Webプログラミングフレームワークを学ぶために本を購入する必要はありません。私がこれまでに経験した他のすべてのWebプログラミングの質問は、いくつかのGoogle検索で回答されています。それとは対照的に、まともなドキュメントが見つからなかったために理解できないWicketの一部がまだあります。また、オンラインで読んだだけではWicketをしっかりと理解しているとは思えないため、フォーラムでの質問は限られています。ドキュメンテーション。
私はWicketを使用していないので、必要に応じて投票してください。ただし、Wicketはコンポーネントベースです。コンポーネントベースのソリューションを好む場合、それはあなたにとって不利にはなりませんが、競合するコンポーネントベースのフレームワークには制限があることがわかりました。
[〜＃〜] jsf [〜＃〜] （これもコンポーネントベースのモデルです）の数年から Spring MVC （より多くのアクションベース）に来た私は次のように感じました束縛は解除されました。 mgvの応答の3番目のポイントは、「HTMLレイアウトでコンポーネントツリーを定義する必要があるため、コンポーネントツリーを動的に定義することはできず、Javaコード」は私の不満の原因の多くを合計している。
Wicketで不愉快なことが2つあります。
Ajax呼び出しは同期的に実行されるため（並行性の問題を回避するためにクライアント側でキューに入れられます）、Ajaxは実際にはJAXにすぎません。編集：明らかに私はこれについて間違っていました、以下のmarting-gのコメントを参照してください。
APIはカプセル化をあまり気にしていないようなので、「これはパブリックAPIの一部ではありません。このメソッドを呼び出さないでください。」と文書化されたパブリックメソッドのlotsが見つかります。 （または類似の何か）。