ExtJSの哲学とは何ですか？シングルページアプリケーション？
ExtJsを使用して次のプロジェクトを作成する必要があります。これは素晴らしいJavascriptライブラリですが、その背後にある考え方を完全には理解していません。 ドキュメントページ を例にとってみましょう。
そのようなextjsでWebアプリケーションを作成することになっていますか？決して更新されるべきではない1つのページ、そしてすべてがAJAXによって行われていますか？
適切な場所に到達するために多くの「クリック」と操作が必要になる可能性がある場合、このようなアプリケーションをどのようにデバッグしますか。バグを修正してブラウザで更新を押して結果を確認することはできません。
助言がありますか？
そのようなExtJSでWebアプリケーションを作成することになっていますか？決して更新されるべきではない1つのページ、そしてすべてがAJAXによって行われていますか？
ExtJSドキュメントのようにアプリケーションを作成する必要はありません。 ExtJSのサンプルページを見ると、個々のページでExtウィジェットと多くのHTMLが混在していることがわかります。私の仕事では、ExtJSを使用している2つの異なるアプリがあります。1つはウィジェットを使用してページを整えるレガシーサイトであり、もう1つはフロントエンドにExtJSのみを使用する本格的なWebアプリケーションです。一度コツをつかんだら、間違いなく後者の方が好きですが、学習曲線はかなり急です。
適切な場所に到達するために多くの「クリック」と操作が必要になる可能性がある場合、このようなアプリケーションをどのようにデバッグしますか。
ここで重要なのは、アプリケーションをモジュール化することです。各コンポーネントを個別に構築し、真空でテストします。これは、アプリケーション全体を含む巨大なJavaScriptファイルでなければならないという考えにとらわれないでください。ほとんどのWebアプリでは、ソースには数十以上のJavaScriptファイルがあり、これらはデプロイメントの目的でのみ結合されています。
テストとデバッグに必要なものは firebug です。これにより、Ajaxリクエストの検査、JavaScriptのライブデバッグなどを行うことができます。
これは、ExtJSを使用して大規模なアプリを作成することに関する一連の記事です。これは、多くの優れた情報を備えたかなりまともな読み物です。
ExtJS 4でのサンプルアプリケーションの構築 Part1Part2Part
どちらの方法でもExtJSを使用しても問題ないと思います。始めたばかりの場合は、最も使いやすい方法でExtJSの「スパイス」を追加する方が理にかなっているかもしれません。とは言うものの、シングルページアプリの作成に使用し始め、バックエンドがJSONのみを出力するようになると、おそらくWebアプリを行っていた古い方法を振り返ることはありません。
最新のAJAXベースのアプリと同じように実行できます RLハッシュを使用してアプリをディープリンクします 。
Gmailは、これがどのように機能するかを示す良い例です。受信トレイにアクセスするには、次の場所に移動します。
連絡先マネージャーに移動するには、次の場所を参照します。
これらの「ページ」は両方とも同じページにあり、アプリを使用している間、ナビゲーションによって実際には別のページにリダイレクトされます。変更されるのはハッシュだけです。
ページが読み込まれたら、window.location.hashを確認し、それを使用してアプリの状態を更新する必要があります。
単一ページではなく、ページ数の少ないアプリケーション
私は以下に基づいて構築された複雑なプロジェクトに関与しました：
- Asp.net 3.5
- WCFWebサービス
- ExtJS 2.1
- DAL + DAO用の.netTiers（CodeSmithを使用）
- SQL 2005 + OLAPキューブ（UpdatePanelsと部分的にサポートされているサードパーティのコントロールを使用したため、アプリ内でこの悪夢の回避策を思い出さないものもあります）これだけで、アプリケーションの非常に基本的な処理が壊れました）
- 既存のExtJSに対するカスタムルックアンドフィール-これはExtJSコスチューム化の最も難しい部分だったので、提供されているテーマの1つに固執することをお勧めします
実際のシングルページアプリケーションは行いませんでしたが、ページ数が大幅に削減されたのは事実です。通常、アプリケーション内の各作業領域は個別のページでした。すべてのインターフェイス処理は、ExtJSを使用するクライアントで、またはExtJSクライアントインターフェイスにデータを提供するWCFサービス内のサーバー側で実行されました。
それはうまくいきました。
今日はおそらく1つ変更します。Asp.net + WCFからAsp.net MVCに移行します。これは、この種のシナリオ向けのビルドです。
デバッグに関しては、他の開発者と同じように、Firebug（Firefoxプラグイン）を広範囲に使用しました。
しかし、ExtJSライブラリの使用は大成功でした。デスクトップのようなデータ量の多いWebアプリケーションを簡単に作成できるようになりました。これは、プロのイントラネットWebアプリケーション開発に最適な統合ライブラリです。 jQueryとそのプラグインを使用すると、コミュニティが提供するプラグインのさまざまな癖に常に取り残されます。 ExtJSはこの点で非常に統一されており、箱から出してすぐに本当に素晴らしいルックアンドフィールを提供します。
これは、ある意味で、Web環境のアプリケーションのデスクトップ感覚と一致するという考えです。つまり、ほとんどすべてがAjaxで機能します。
デバッグに関しては、firebugはあなたの友達です。しかし、バグを取得するために多くのクリックが必要になる可能性があるデスクトップアプリケーションをデバッグすることもそれほど違いはありません。
Extjs画面をロードするために、私が「クロージャー」形式と呼んでいるものと一緒に、onHashChangeリスナーを使用できます。 シングルページextjsアプリケーション の構築方法に関する記事を書きました。
ExtJのテストに関して...
これは、ExtJsコンポーネントをテストするテストツールです（このツールはExtJsで作成されました！）
個人的にはまだ使ったことがないのですが、デモ動画を見てみたらとても素敵ですね！
おそらく、コミュニティのメンバーは、ExtJを具体的にテストする代替ツールを知っているかもしれません。
PS：私はSencha（ExtJs）やBryntum（Siesta）とはまったく関係がありません。私は顧客レベルでExtJを使用しています。
このアプリケーションでは、「ページ」間の切り替えを処理するカスタムPageクラスを作成しました。すべてのページは、クラスを返すExtJSコンテナーで構成されており、URLの末尾に#hash値を設定することで履歴を保持します。
このアプローチを使用すると、ExtJSライブラリをすべてのアセットと一緒に一度ロードします。これにより、パフォーマンスとアプリの流動性が大幅に向上します。
ExtJSでASP.NetMVCを使用しています。 1ページのアプリケーションではありませんが、近くにあり、1ページのアプリケーションのように感じます。
また、数百ページのWebフォームアプリケーションがあります。このアプリにいくつかのExtJS UIウィジェットを適用し、多くのIFrameを使用しましたが、それでも機能し、見栄えがします。しかし、私はWebフォームモデルの使用を楽しんでおらず、できる限りそれを避けようとしています。
私見では;
- asp.net mvcプラットフォームはwebformsプラットフォームよりも優れています。
- コントローラは、アクション処理に非常に適しています。
- パーシャルはhtmlコンテンツを生成するのに役立ちます（足場はここで大いに役立ちます）
ExtJS
- ナビゲーション用、
- リスト、
- 検索、
- コンテンツの編集、
- お知らせ、
- 他のすべてのためにほとんど...
全体として、ExtJSは優れたフレームワークです。
あなたはそのように書く必要はありません。時々それはそのようにそしてより速く見栄えがする（新しいページのための更新なし）。
いくつかの自動テストツールを使用して、または自分でそれらを作成するjavascriptの自動記録を行うことができます。通常、ページ全体をデバッグすることはそれほど良い考えではありません。モジュール式に構築すると、簡単になります。問題を切り分ければ簡単です。
また、デバッグにfirebugを使用することを検討してください。
提案：私はあなたが何をしているのかによります。高度にインタラクティブなページを作成している場合は、そのようにすることをお勧めします。それはより速く、ajaxリクエストはサーバーへの負荷を減らすことができます。反対に、そうするのにはもっと時間がかかるでしょう。