2

私は Django プロジェクトを立ち上げており、ユーザーの学校の色に基づいた多くの配色で UI を使用することができれば素晴らしいと思います。私は、style.css にコンパイルされる他の .less ファイルの束と一緒に、ベースの variables.less ファイルを持つという幻想を抱いています。

しかし、ユーザーが学校の色を設定すると、 blue.variables.less ファイル (青のプリセットを選択した場合) または school123.variables.less ファイル (すべてのファンシーがあり、カラー ピッカーを使用して独自の色を作成した場合) が生成されます。 scheme) を作成し、すべてを blue.style.css または school123.style.css にコンパイルします。これが、ページを提供するときに読み込む .css ファイルです。

これが崩壊する方法はたくさん想像できます。例えば、forms.less または layout.less に更新をプッシュするときに、これらすべてのファイルを再処理するにはどうすればよいでしょうか。

これを行うより良い方法はありますか？私は自分の指を生でグーグルで検索しましたが、この狂気を試みている人は見つかりませんでした.

4

1 に答える 1

3

ユーザー固有の配色を使用できるようにするという目標を達成する方法はたくさんありますが、それぞれに長所と短所があります。

名前を付けたファイルで Bootstrap のようなフレームワークを使用していると思います。

オプション 1: 色固有のスタイルのインライン CSS (推奨)

これは、パフォーマンスとシンプルさから私が好むオプションです。ユーザーごとにカスタマイズした色をそれぞれ保存したり、特定の学校を表す色を再利用できるようにモデルを作成したりすることもできます。これはデータベースに保存され、非常に多くの類似したファイルを生成することなく、非常に多数のカラー スキームに拡張できます。

color 変数を使用するスタイルを持つテンプレート コードでスニペットを作成します。

base.html

{% include "color-snippet.css" with main-color="{{ user's main color }}" alt-color="{{ user's alt color }}" %}

color-snippet.css (このファイルはテンプレート エンジンによって処理されるため、テンプレート ディレクトリにあります。

<style>
.some-style {
    color: {{ main-color }} !important;
}
</style>

したがって、これの大きな欠点は、変数を超えて Bootstrap をカスタマイズする必要があることです。less ファイルを grep して、生成されるすべてのクラスを見つけ、スタイルを CSS でスニペットにコピーする必要があります。新しいBootstrapにアップグレードしたい場合は、前もっていくらかの投資が必要ですが、スタイルの色部分を分離して、実行時に動的に派生させることができます.

あなたのcollectstaticステップの外でlessのコンパイルを扱う必要がないので、私はこのアプローチを好みます。

オプション 2: LESS のクライアント側コンパイル

動的に作成され、必要な変数を返すファイルを Django に提供させることができます。次に、クライアントで less.js をコンパイルします。

これには、静的パスの一部ではない Django によって処理される URL パス (/style/variables など) をベース テンプレートに追加し、ビューでハンドラーを作成してから、少ないファイル変数となるテキスト コンテンツを返すことが含まれます。 .

オプション 3: LESS のサーバー側コンパイル

私はDjango Pipelineを使用して、less から css へのサーバー側のコンパイルを行います。Django アプリケーションを操作するには、セットアップが必要です。開発モードでは、Django Pipeline はすべてのリクエストで関連する less ファイルを CSS ファイルにコンパイルします。プロダクション モードでは、コンパイルされたファイルへの適切なファイル パスを指します。それはにフックするcollectstaticので、あなたの less はコンパイルされますcollectstatic。

このアプローチの最大の問題は、静的ファイル (以下 + css ファイルが css にコンパイルされるもの) のマッピングが設定ファイルで定義されていることです。これを更新すると、サーバーの再起動が必要になります。Djangoパイプラインの仕組みに基づいて独自のサーバー側のコンパイルを減らすことができますが、サーバーの再起動が必要なものでマッピングを定義する代わりに、マッピングのロジックを使用できます。

これは大変な作業であり、Bootstrap のコンパイルが少ないことは、要求ごとに行うのは簡単ではありません。

Django サーバー プロセスを再起動する必要のない独自のマッピングを作成した場合は、いつでも collectstatic を実行して新しい css ファイルを作成できます。これにより、すべてのリクエストでのコンパイルが回避されます。

この最後のアプローチはあなたが言及したものに最も近いですが、色固有のスタイルを分離してdjangoテンプレートを使用してカスタマイズするよりも、はるかに多くの作業とエラーが発生しやすいようです.

最後のアプローチは、事前にすべてのマッピングを作成し、実行時に独自のマッピングを生成させないため、スキームの数がかなり少ない場合にもうまく機能します。彼らはそれらを提案することができ、定期的なリズムでそれらを更新することができます.

于 2013-10-18T19:27:07.177 に答える