3

ねえ、私は GWT アプリを開発していて、現在 CSS 部分に直面しています。公式サイトでこのトピックについてよく読みましたが、まだいくつか質問があり、誰かが私にヒントを与えてくれることを願っています.

  • CSSResource を使用すると、css スタイルがコードにコンパイルされます。したがって、アプリを再コンパイルせずに変更することはできません。しかし、私がやりたいのは、スタイルを「外部」から編集できるようにすることです。
  • アプリを再度コンパイルしないと色や画像を変更できないため、この CSSResource は何のためにあるのでしょうか。
  • これを行うにはいくつかの方法 (.css ファイル、CSSResource、ui.xml のスタイル) があるため、CSS を使用する最良の方法は何ですか?

私の考えでは、通常の CSS ファイルのみを使用してすべての「変更可能な」ものを処理し、このファイルを頭に追加しています。この CSSResource の利点がわかりません。うまくいけば、誰かが私を助けてくれます。ありがとう。

4

1 に答える 1

7

それはすべて、CSS の使用方法に依存します。小さな変更を適用する必要がある場合は、最初に Firebug/類似ツールで「ライブ」でテストしてください。設計段階 (アプリケーションをどのようにスタイルするかについての最終的なビューがまだない場合) では、通常の CSS ファイルで作業することをお勧めしますが、一般的なスタイルが明確になったらすぐに ClientBundle/ に切り替える必要があります。 Cssリソース。

なんで？CssResource のドキュメンテーションページにリストされている目標について考えを書き上げて、答えさせてください。

  • 主要な

    • GWT を認識しない CSS パーサーとの互換性 (つまり、すべての拡張子が有効な CSS 構文である必要があります)
      これは、ブラウザーで表示しただけでスタイルシートが必ずしも意味を持つことを意味するものではありません。つまり      、有効な CSS 構文のみを使用したいということです。他のパーサーにとって意味不明な構文糖衣ではありません-あなたの観点からはそれほど重要ではないかもしれません（ただし、結果として、既存のスタイルの構文を変更する必要はありません）
    • 構文の検証-非常に重要なポイント、IMHO。欠落している (スペルミスの可能性がある) CSS クラス、構文エラーなどをチェックするようなものを取得します。これは、ブラウザー固有の開発者ツール (Firebug) を介して (通常は苦痛を伴いながら) 追跡する必要があったものです。ここでは、これらのエラーをコンパイル時の早い段階で取得します (Google Eclipse プラグインを使用すると、さらに高速になります)。
    • 縮小化- これはありきたりの縮小化ではなく、セレクターとプロパティのマージも行います。次のポイントも参照してください。
    • GWT コンパイラーを活用する- CSS クラスが使用されていない場合 (GWT コンパイラーはアプリケーション全体の概要を把握しているため、そのような区別を行うことができます)、それは刈り込まれ、コンパイルされたコードに含まれません。いくつかの設計変更後に残っていた CSS クラスを何回見つけましたか? これはそれを処理します (CSS モジュール化のポイントも参照してください)。
    • ブラウザごとに異なる CSS を自動的に- この方法で生成された CSS は JS コードに含まれているため、ターゲット ブラウザに合わせて最適化できます (また、最適化されます)。すべての順列に長い IE ハックを含める必要はありません!
    • コンテンツの静的評価- すでに述べた

  • セカンダリ

    • 基本的な CSS モジュール化
      • 依存性注入 API スタイルを介して - 必要に応じて CssResources を注入できます (たとえば、アプリケーションでカスタム テーマを容易にするため)。
      • ウィジェットは、必要な場合にのみ独自の CSS を挿入できます。これは私のお気に入りのポイントの 1 つですが、最初はその重要性がわかりませんでした。(通常は) 巨大でモノリシックな CSS ファイルを、ウィジェットごとに 1 つずつ小さなモジュールに分割します。 UiBinder (CssResource内部で使用) に加えて、アプリケーション全体のスタイル用におそらく 1 つのグローバル CssResource を使用します。これにより、CSS スタイルがよりクリーンで維持しやすくなります (少なくとも、私の経験では)。これは、コードがその特定のウィジェットを使用していない場合 (ocde 分割を使用していて、まだロードされていないため)、それらのスタイルをダウンロードしないことも意味します。
    • BiDi (Janus スタイル?) - 双方向テキストのサポート、使用していませんが、ドキュメントは有望に見えます :)
    • CSS 画像ストリップ- 自動魔法の画像スプライト生成 - これ以上何が言えるでしょうか? ;)
    • 「CSSを改善する」
      • 定数- CSS 仕様でこの機能をいつも見逃していました - 原色を変更するときは、ファイル全体でそれを見つけて置き換える必要があります (いくつかの場所で古い色を使用したい場合に、エラーが発生する可能性があります) ) - これにより、定数を導入することで、より直感的になります (有効な CSS 構文を介して、実行時のペナルティなしで)
      • 簡単な式- ドキュメントをざっと読んで、そこにある可能性を確認する必要があります。本当に素晴らしいものです

  • 三次

    • ランタイム操作 (StyleElement.setEnabled() は多くのケースを処理します) - スタイルシート インジェクション (ランタイム中) で、いくつかの値が評価されます - これにより、スキニングなどが可能になります。
    • コンパイル時のクラス名チェック (Java/CSS) - これの (明らかな) 利点については既に述べました
    • 難読化- これも非常にクールです。GWT コンパイラは、CssResources 内のすべてのスタイルを安全に難読化できます。これは、アプリケーション全体の概要を把握しているためです。したがって、名前の衝突は不可能です。これは、アプリケーションのサイズにどのように影響するかを心配することなく、長い (ただし長すぎない ;)) 意味のあるクラス名を使用できることを意味します。ランダムな文字列。これにより、2 つのウィジェットでスタイルを定義することもできます.warning。コンパイラは、これらの 2 つのスタイルが異なる名前空間 (異なるウィジェット) にあるため、異なる方法で処理する必要がある (つまり、異なる名前に難読化する) 必要があることを認識します。

スタイルインジェクションについて

このクラスStyleInjectorでは、実行時にスタイルを挿入できます。さらに、CssResource（少なくともドキュメントによると、まだ試していません）ランタイム置換が可能です。たとえばCssResource、次を含む a を注入すると:

@eval userBackground com.module.UserPreferences.getUserBackground();
div {
  background: userBackground;
}

はuserBackground評価され、注入されます (実行時に解決される定数とは対照的に)。

于 2010-10-06T08:24:28.853 に答える