я не вижу, что проблема использовать добирается, хотя, я использую ее для простых вещей, где имеет смысл сохранять вещи на строке запроса.
Используя его для обновления состояния - как ТО, ЧТОБЫ ПОЛУЧАТЬ delete.php?id=5
для удаления страницы - очень опасно. Люди узнали это, когда веб-акселератор Google начал выбирать URL с упреждением на страницах - он поразил все 'удалить' ссылки и вытер данные народов. То же самое может произойти с пауками поисковой системы.
Я думаю, что есть более простой способ, чем писать собственные ORMS, чтобы получить желаемую административную интеграцию. Я использовал его в приложении, которое позволяет управлять учетными записями электронной почты Webfaction через API панели управления.
Взгляните на models.py, admin.py и urls.py здесь: django-webfaction
Чтобы создать запись на странице индекса администратора использует фиктивную модель, которая управляется = False
Зарегистрируйте эту модель у администратора.
Затем вы можете перехватить URL-адреса администратора и направить их на свои собственные представления.
Это имеет смысл, если действия добавления / редактирования / удаления, предоставляемые администратором, имеют смысл для вашего приложения. В противном случае вам лучше переопределить индексы администратора или шаблоны списка изменений, включив в них свои собственные действия
Настоящая мощь contrib.admin - django Forms . По сути, инструмент администратора в основном автоматически генерирует форму для соответствия модели с добавлением небольшого количества маршрутизации urls.py. В конце концов, вероятно, было бы проще использовать django Forms отдельно от инструмента администратора.
Django ORM имеет подключаемый бэкэнт, что означает, что вы можете написать бэкэнд для вещей, которые не являются СУБД. Это, вероятно, довольно сложная задача, но для начала лучше всего обратиться к докладу Малкольма Трединника на DjangoCon 2008, Внутри ORM .
В противном случае вы могли бы полностью обойти ORM и написать формы вручную для нужного вам доступа.
вы можете "имитировать" некоторый класс, чтобы он выглядел как модель, но выполнял прокси для ваших API
fe
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