5

私は基本的にこれで構成されるかなり大きなプロジェクトを構築しています:

サーバー 1: アイスベースのサービス。セッション処理用の Glacier2。Glacier2 へのアクセスを許可するファイアウォール。

サーバー 2: Glacier2 経由の Ice サービス用の Web インターフェイス (読み取り、パブリック)。Glacier 2 経由の Ice サービスの管理インターフェイス。

気になる点はWebインターフェースです。Django を使いたいのですが、どちらも Python で書かれており、信じられないほど便利な自動管理パネル ジェネレーターを備えているからです。

Web インターフェイスはデータベースにアクセスしません。Glacier2 ルーター経由でサーバー #1 の Ice サービスに接続し、それらのサービスによって公開された API を使用してデータを操作します。

おそらくご存じのとおり、Django の管理世代は Django の ORM の使用に依存しています。アクセスするデータベースがないため、使用していません。

したがって、管理パネルを生成する必要がありますが、ORM が通常行うような標準的なデータ アクセスを行う代わりに、「db-access」呼び出しをインターセプトして Ice サービス呼び出しに変換し、サービスの出力を取得する必要があります (存在する場合)、ORM が通常返すものに変換し、制御を Django に返します。

どうすればこれができるか知っている人はいますか？サブクラス化するには何が必要ですか？具体的なアイデアはありますか？

御時間ありがとうございます。

4

4 に答える 4

7

カスタム ORMS を作成して、必要な管理統合を取得するよりも簡単な方法があると思います。コントロール パネル API を介して Webfaction メール アカウントを管理できるアプリで使用しました。

ここで models.py、admin.py、および urls.py を見てください: django-webfaction

管理インデックス ページにエントリを作成するには、managed=False のダミー モデルを使用します。

そのモデルを管理者に登録します。

次に、管理者の URL をインターセプトして、独自のビューに誘導できます。

管理者が提供する追加/編集/削除アクションがアプリにとって意味がある場合、これは理にかなっています。それ以外の場合は、管理インデックスまたは変更リスト テンプレートをオーバーライドして、独自のカスタム アクションを含めることをお勧めします。

于 2009-11-28T21:11:35.773 に答える
3

contrib.admin の真の力はdjango Formsです。本質的に、管理ツールは基本的にフォームを自動生成してモデルに一致させ、少しの urls.py ルーティングを挿入します。最終的には、管理ツールとは別に django フォームを使用する方が簡単でしょう。

于 2009-11-28T20:15:47.320 に答える
1

一部のクラスを「モック」してモデルのように見せることができますが、API にプロキシします

フェ

class QuerysetMock(object):
    def all():
        return call_to_your_api()
    [...]


class MetaMock(object):
     def fields():
         return fields_mock_objects..
     verbose_name = ''
     [...]

class ModelMock(object):
    _meta = MetaMock()
    objects = QuerysetMock()

admin.site.register(ModelMock)

これはうまくいくかもしれません..しかし、django.modelと互換性のある多くのことを行う必要があります

于 2009-11-28T21:06:28.683 に答える
0

django ORM にはプラグ可能なバックエントがあります。つまり、RDBMS ではないもののバックエンドを作成できます。これはおそらくかなり大きな作業ですが、DjangoCon 2008 での Malcolm Tredinnick の講演、Inside the ORMから始めることをお勧めします。

そうしないと、ORM を完全にバイパスして、必要なアクセスのために手動でフォームを作成することができます。

于 2009-11-28T20:13:59.210 に答える