4

Python を学習し、最初の Web アプリを作成しています。私はdjangoのチュートリアルを進めてきましたが、クライアント側のやり方を考え始めたところです。私はそれをWeb 2.0風にしたいと思っており、データベースからリストを表示するためのAJAX/javascript機能と、日付選択、オートコンプリートなどのクールなものが必要です.

html/css/javascript (特に jquery) が最も一般的なオプションのようです。初心者なので、qooxdoo や sproutcore などのフレームワークに興味がありますが、それらがどのように機能するのか正確にはわかりません。例えば：

  1. あるアプリのコードを別のアプリで簡単に再利用できますか?
  2. 1ページの静的ページも簡単に作成できますか?
  3. gmail のような 1 ページのみですか? それは問題ですか？
  4. それを使わないよりも本当に簡単ですか？つまり、フレームワークの学習曲線は html/css/javascript の学習と同じですか?
  5. これらのタイプのアプリは、オーバーヘッドが大きいため読み込みが遅くなりますか?

または、

これらのいずれかを使用する/使用しないことの長所/短所は何ですか?

初心者さんへのアドバイス大歓迎です！

4

2 に答える 2

5

qooxdoo の観点からの回答は次のとおりです。

あるアプリのコードを別のアプリで簡単に再利用できますか?

はい、できます。複数のアプリに含めることができる「ライブラリ」でコードを整理できます。ただし、各アプリは個別の全体 (ライブラリ コードが静的にリンクされているバイナリと考えてください) であり、.js ファイルを手動でコピーする必要はありません。

1ページの静的ページも簡単に作成できますか?

ここで何を意味するのかわかりません。

gmail のような 1 ページのみですか?

はい、qooxdoo でシングルページ アプリケーションを構築します。

それは問題ですか？それを使わないよりも本当に簡単ですか？つまり、フレームワークの学習曲線は html/css/javascript の学習と同じですか?

それは主にあなたのバックグラウンドに依存します。OO をよく理解している場合、Qt や Swing などの OO インターフェース ライブラリの経験がある場合でも、qooxdoo を理解するのは非常に簡単です。そのような場合、基礎となるテクノロジーをあなたから保護するOOクラスライブラリに対して基本的に取り組んでいるため、学習の労力はhtml/css/javascriptに比べて少ないと私は主張します. (これは良いことです。たとえば、クロスブラウザーの CSS を適切に処理するのは困難です)。

これらのタイプのアプリは、オーバーヘッドが大きいため読み込みが遅くなりますか?

私はそう言うでしょう。インフラストラクチャにペナルティを支払います。しかし、実際の Web GUI が必要な場合は、それだけの価値があります。

これらのいずれかを使用する/使用しないことの長所/短所は何ですか?

他の場所で述べたように、それは実際に何を達成したいかによって異なります。あなたの質問から、「データベースからリストを表示する」だけでなく、高レベルのウィジェット (日付選択)、クロスブラウザー イベント処理 (自動補完) を備えたインタラクティブなユーザー インターフェイスが必要であることがわかります。おそらく他のコントロール、レイアウト管理などです。そのような場合、長所が短所を上回ると私は言います。

しかし、これは投資であり、1 回限りのプロジェクトとしては多すぎると言えます。また、いくつかのリスト ビューだけが必要な場合は、Django テンプレートを使用してください。Javascript を少し追加することもできます。

于 2010-06-29T21:13:00.113 に答える
4

HTML の T はテキストを表すことに注意してください。HTML はドキュメントを表示するように設計されています。JavaScript により、これらのドキュメントにインタラクティブ性が追加されました。これは、DOM オブジェクトを操作するデスクトップ アプリのようなエクスペリエンスを作成するために JavaScript が使用されるまでは、(ある意味で)「変質した」ものでした。

現在、Web アプリを見ると、次の 3 つの主要なカテゴリがあります。

  1. このようなアプリ
    は、基本的にコンテンツ/ドキュメント配信サービスです。一部のドキュメントを閲覧、検索、編集、投稿できます。それは基本的にそれです。stackoverflow は、このカテゴリの良い例です。
  2. Web インターフェイス
    このようなアプリは、サーバー上で実際に実行されるアプリケーションに Web フロントエンドを提供します。これらは、サーバー上で実行されるビジネス ロジックへのインターフェイスとして機能します。オンライン バンキング アプリはその良い例であり、さまざまな種類のサービスの Web インターフェースです。古典的なGoogleページは、ある意味で.
  3. RIA
    これらのアプリはクライアント上で完全に実行されます。それらはサーバーからデータを取得し、クライアント側でそのデータを操作し、場合によっては進行状況/結果を送信できるようにするユーザー インターフェイスを提供します。

もちろん、これらのカテゴリの 1 つだけに分類できないアプリもあります。
Web サイトでは、セマンティックでクリーンで有効な HTML を作成することが非常に重要です。これには多くの理由があります。SEOとアクセシビリティは最も重要なものです。
Web インターフェイスと RIA の場合、これは当てはまりません。ここで、クライアント側では、最も重要なことは使いやすさです。Web インターフェイスの場合、ページ全体の更新を避け、ユーザー入力を最大限に容易にすることが望ましいです。RIA の場合、これは必須です。どちらのカテゴリも HTML を使用してドキュメントを表すのではなく、ユーザー インターフェイスを構築します。Web インターフェースの場合、ユーザー入力の複雑さに応じて、従来のフォームでうまくいく場合があるため、この点を考慮して、それらを Web サイトまたは RIA として扱うことができます。

Web サイトは HTML を使用して実際のデータを表し、CSS を使用して視覚的な外観を定義し、JavaScript を使用して対話性を追加しますが、Web インターフェイスと RIA は DOM オブジェクトを使用して UI を作成し、CSS を使用して UI をスキンし、JavaScript を使用してクライアント側のビジネス ロジックを実装します。

つまり、使用しているプラ​​ットフォームは同じですが、実際にはまったく異なることをしているのです。テキストモードのようなものと考えてください。画面上の文字は、テキストまたはGUI 要素を表す場合があります。(このアナロジーでは、Web インターフェイスはコマンド プロンプトになると思います:D)。

qooxdoo や sproutcore などのフレームワークは、RIA の作成を容易にするように設計されています。このアプローチでは DOM はある意味で誤用されているため、UI ロジックと基礎となる DOM 操作の間を橋渡しするために必要な抽象化を提供します。これらはインタラクティブな UI を作成するために設計されたツールではないため、HTML と CSS の必要性を無効にします。

目的に応じて、適切なツールを選択する必要があります。

于 2010-06-29T17:51:44.437 に答える