Я только начинаю использовать Django для личного проекта.
Каковы преимущества и недостатки использования встроенного приложения для администратора или интеграция моих административных функций в самом приложении (путем проверки request.user.is_staff)?
Это вики сообщества, потому что это можно считать опросом.
Это действительно зависит от проекта, который я предполагаю. Хотя вы можете делать все в администраторе, когда ваше приложение становится более сложным с помощью администратора, он становится более сложным. И если вы хотите, чтобы ваше приложение действительно было легко управлять, вы хотите контролировать каждую мелочь, что не совсем возможно с помощью приложения admin.
Я думаю, вы должны увидеть это следующим образом:
Использование администратора django: сэкономить время на его запись, потерять время, используя его.
Перемещение вашего собственного администратора: потеряйте время, записывая его, экономя время, используя его.
Я использую приложение администратора Django по ряду причин. Во-первых, при написании приложения для администрирования может быть довольно сложным и потребуется некоторое время, если вы хотите сделать это правильно, а django.contrib.admin - бесплатно и работает из коробки. Во-вторых, он действительно хорошо разработан и очень хорош для работы (даже для нетехнических пользователей). В-третьих, он охватывает множество распространенных случаев, и не представляется разумным тратить время на переписывание, пока вы не уверены, что не можете сделать иначе. В-четвертых, на самом деле это не так сложно настроить. Например, добавление кнопок akismet mark-as-spam и mark-as-ham действительно было частью торта.
Так легко выборочно переопределить части администратора в той или иной степени.
Вы можете:
Переопределить шаблоны администратора в приложении по умолчанию или даже по модели.
Переопределение представлений администратора путем наследования и подкласса
Устраните URL-адрес администратора, разместив его перед ним в urls.py и предоставив свои собственные интерфейсы, основанные на взгляде администратора.
... и многое другое.
Итак, начните с администратора, а затем запустите все необходимые функции, где вам это нужно.
Существует множество приложений, которые умеют делать с администратором. Например:
Также найдите django-snippets для связанных с администратором фрагментов и эта страница имеет множество информации.
Я с грустью обнаружил, что в то время как приложение admin django экономит много времени, оно становится затруднительным позже, так как ваш заказчик требует больше функций, которые нелегко интегрируются с интерфейсом администратора по умолчанию. Вы можете использовать два типа админ-инструментов: администратор django (для приложений, требующих простой ввода данных), и собственный настраиваемый интерфейс администратора для других приложений, для которых требуется более богатый интерфейс.
Рассмотрим использование администратора Django, но с вашими собственными виджетами ручной работы для определенных полей. Вы можете создавать сложные детали формы и сообщать администратору использовать свой код для ввода и отображения любого конкретного поля или всех полей типа.
Jannis сделал несколько классных вещей, и его работа показывает вам, насколько это просто: http://jannisleidel.com/2008/11/wysiwym-editor-widget-django-admin-interface/
Проект, над которым я работаю, недавно включил сборщик времени, который использует выпадающие списки для разных частей времени (h, m, s). Другое поле указывает, какие дни недели повторяются... это будет используйте 7 флажков для дней недели и сохраните их в базе данных как маринованный dateutil.rruleset. Затем вы просто даете подсказки администратора, какие виджеты использовать для разных полей.
Он включает определение вашего класса данных, собственного виджета, который создает подклассы. Виджет, ваше собственное поле, которое создает подклассы. Поле и модель. Каждый из трех классов хорош, прост и чист и отвечает за переход из базы данных в модель, модель в виджет и обратно через эти два шага. Это действительно красота.
Созданные вами поля будут одними из наиболее многоразовых интеллектуальных объектов, которые можно накопить... и вам не нужно писать собственный администратор с нуля.
Я бы рекомендовал включить сайт администратора практически для каждого типа проекта. Стоимость его настройки довольно низкая, и это дает вам достаточно удобный механизм для проверки и модификации вашего сайта.
Если ваш сайт имеет в основном односторонний поток информации, от веб-мастера до посетителей, тогда, вероятно, все, что вам нужно, - это сайт администратора.
Если, однако, ваш сайт имеет более богатое взаимодействие между его пользователями, вам нужно будет создать представления django, которые могут включить это взаимодействие, а также ограничить доступ к тем, что действительно могут делать пользователи.
Я бы пошел с функциональностью администратора Django, написав свой собственный. Вы можете настроить администратора Django, добавив собственные шаблоны для администратора, собственные виджеты и т.д. Я работаю над проектом с очень настроенным администратором Django. Если бы мы решили написать его вручную, это заняло бы в 4 раза больше времени. Я просто не вижу сценарий, в котором вы хотели бы написать свой собственный.