私はしばらくの間Djangoの管理パネルを内部ユーザーにうまく使用してきましたが、最近それをカスタマイズしようとしているときにレンガの壁にぶつかりました。それにあまりにも多くの時間を費やしているのではないかと思います。だから、私の質問は：
Djangoの管理パネルは、一時的なスキャフォールディング、つまり、アプリケーションの初期開発中にのみ使用され、Railsのスキャフォールディングと同様のカスタムコードに置き換えられることを目的としていますか？
明らかに、管理パネルを使用することで、多くの機能を無料で入手できます。新しい機能が追加されると、それらも無料で入手できます。他の人は何をしますか？
管理者が一時的な足場になることを意図しているとは言えませんが、多くの場合、それは最良の選択ではないかもしれません。私は、プロデューサーとエディターのワークフローインターフェイス全体の基盤として管理者を使用している、非常に大規模で有名なメディア会社と協力してきました。残念ながら、管理者をいつ使用するか、いつ使用しないかについての意思決定プロセスは、Djangoの内部に関する全体的な知識から大きく恩恵を受けます。行き詰まらない時期を知る経験を積む前に、おそらく数回行き詰まるでしょう。：p
管理者の「カスタマイズ性」は、ある程度主観的なものになる可能性があります。私はチームがそれを彼らの意志に曲げるのを見てきましたが、それはまた、モデル、フォーム（そして当然のことながらModelFormsやFormSetsのようなもの）、そしてテンプレートの詳細という下位レベルのかなり良い実用的な知識を必要とします。従来の知識やベストプラクティスの多くは、まだ整理されたドキュメントに反映されていないと思います。ソースコードを掘り下げる準備をしてください。良いニュースは、フレームワークでファーストクラスのエンティティのいくつかを利用する方法について、おそらくはるかに深い理解が得られることです。悪いニュースは、フォームの単一の入力を変更するのに1日のほとんどがかかったことに、上司がおそらく満足しないことです。
最近の機能強化により、管理URLスペースの下に独自のビューを簡単に配置できるようになったため、ニーズに合わせて独自のビューを作成し、標準の管理ページ内の適切な場所にリンクを配置するアプローチを検討できます。私は一般的に、Djangoを初めて使用する人や、管理者のカスタマイズを始めたばかりの人には、独自の管理ビューをロールすることを強く検討することをお勧めします。結局のところ、DjangoはすでにCRUDスタイルのアプリを途方もなく簡単に作成できるようにしており、プレゼンテーションや動作を変更したいときはいつでも、厳格なシステムと戦っているように感じる必要はありません。
Django Adminは、それが提供するデフォルトの追加/変更/削除処理以外のことをすることに価値がないもののためのものです。
データベースはルックアップテーブルと管理テーブルでいっぱいです。たとえば、エンドユーザーには表示されない郵便番号から州へのマッピング。バックグラウンドバッチジョブ実行のログ。
あなたのアプリにはおそらく、これらの種類の多かれ少なかれ「管理」であるいくつかのテーブルがあります-誰かがそれらを維持しますが、ユーザーの大規模なコミュニティではありません。
アプリには、エンドユーザーが追加/変更/削除するためのテーブルがいくつかある可能性があります。このアクティビティ用に、カスタマイズされた広範なページを提供することをお勧めします。
Djangoはニュースビジネスで育ちました。ライターとエディターは（管理インターフェースを使用して）データを準備します。顧客は、カスタマイズされたWebページを通じてデータを読み取ります。
管理ページを使用する管理スタッフがいます。お客様のためにページをカスタマイズしました。両方を使用します。
社内管理者には、ほとんどすべてのデフォルトの管理ページを提供しています。選択したテーブルのデフォルトの管理者を顧客側の管理者に提供します。また、慎重に作成されたアプリケーション固有のページをお客様に提供します。
私が最初にDjangoを始めたとき、私は約6か月前に同様の質問をしました。
適切なサイズのプロジェクトに組み込みのDjango管理者を使用する価値はありますか？
その特定のアプリケーションでは、Django adminを使用しないことを選択しましたが、それは後から考えると非常に賢明な決断でした。それ以来、私は一般的にそれを使用していませんが、時々それが素晴らしい状況があります。私にとって、それは本当にユーザー次第です。クライアント用のカスタムデータ駆動型アプリを構築していて、クライアントが提供する機能セットを使用している場合、Django管理者を使用したくはありません。そのような場合、ほぼ確実に、管理者で作業を開始するのに非常に苦労する可能性のある変更が加えられます。そして、それが進化するプロジェクトである場合、これらの変更はますますハックになり、サイトのDjango管理者以外の部分に断片をリッピングし始める必要があります。その時点で、実行するための2つのインターフェイスがあります。もの。
ただし、クライアントがアプリの動作方法を受け入れるという考え方を持っている場合は、テーブルと処理するデータが通常1：1で対応していると仮定すると、Django管理者は問題ありません。
Brian Luftが言ったように、CRUDアプリのインターフェースを作成するのは本当に簡単なので、将来カスタマイズが必要になると感じた場合は、最初から独自に作成するのが最も簡単かもしれません。スーパーユーザーとしての自分のニーズに合わせて、いつでもdjango管理者を維持できます。これは通常私が行うことなので、通常のユーザー管理者には表示されない可能性のあるフィールドを変更するためのテーブルレベルのアクセス権を簡単に持つことができます。
いいえ、Railsの足場とは比較しません。あなたの質問から、あなたがどのような問題に直面しているのかは明らかではありません-例を挙げていただけますか？
カスタムModelAdminクラスを追加することで、管理者に対して実行できる多くのカスタマイズがあります。フィールドの非表示、追加フィールドの表示、同じページ上の関連アイテムの編集の許可、または外部キーフィールドに表示されるオプションの制限/フィルタリングです。また、フロントページに並べ替え、フィルター、検索フィールドを追加することで、ユーザーが見つけやすくすることもできます。新しいバージョンのDjangoでは、一度に複数のオブジェクトに適用できる独自のカスタムコマンドを作成することもできます。
ただし、基本的な変更リストと編集フォームに問題がない場合は、モデル固有のテンプレートを作成し、デフォルトの管理者テンプレートをオーバーライドすることで、それらを完全にカスタマイズできます。
いいえ、確かにサイトの管理に使用できますが、Djangoが言うように。信頼できるユーザーのみ。したがって、cmsを作成する場合、それは素晴らしいことです。（うまくいけば）バックエンドユーザーは信頼できるユーザーになるからです！