Как вы на самом деле используете одноразовое приложение django в проекте?

Этот вопрос беспокоил меня в течение нескольких дней, и я пробовал просить во многих местах советы, но, похоже, никто не может ответить на него четко или даже дать ссылку на ответ.

Я также пробовал поиск учебников, но я просто не могу найти какой-либо учебник, в котором объясняется, как вы будете использовать многопользовательское приложение django для сторонних разработчиков (большинство учебных пособий объясняют, как их писать, никто не объясняет, как их использовать).

Кроме того, я посмотрел здесь:

Как повторно использовать приложение многократного использования в Django – это не объясняет, как его использовать в самом проекте

и здесь:

Как связать несколько многоразовых приложений Django вместе? – Ответ на аквапланету имеет смысл, но я думал, что задаю этот вопрос, чтобы решить ментальный блок, с которым я столкнулся, пытаясь понять это.

Чтобы лучше объяснить это, позвольте мне сделать это на примере (заметьте, это не то, что я на самом деле строю).

Я создаю проект, который действует как Reddit. У меня будут пользователи, ссылки и голосования / баллы. Исходя из этого грубого примера, я хочу повторно использовать 3 (произвольные) сторонние приложения: пользователь, голосование / точки и ссылки.

Я решил использовать каждый из них как любой другой пакет python (что означает, что они будут рассматриваться как пакет, и ни один из их кодов не должен быть затронут) [будет ли этот метод действительно работать? Или вы должны иметь возможность редактировать сторонние приложения для создания проекта?)

Теперь с этими приложениями в рамках моего проекта я буду использовать основное приложение для обработки всего материала шаблона (что означает, что все, что я вижу в интерфейсе, будет в одном приложении).

Затем я либо использую то же основное приложение для пользовательской логики (в views.py), либо я разберу эту логику между различными приложениями (но все равно буду использовать одно приложение только для интерфейса).

Из вышеприведенных 3 пунктов, применима ли эта структура (или она может работать)?

Теперь скажем, что эта структура применима, и я использую одно основное приложение для интерфейса и пользовательской логики.

Что бы я написал в models.py? Как мне интегрировать вещи из трех многоразовых приложений в основной файл models.py?

Как я могу ссылаться на повторно используемые приложения в views.py? Давайте возьмем пример contrib.auth

Благодаря этому встроенному приложению для выхода из системы я бы написал:

from django.contrib.auth import authenticate, login, logout @login_required def user_logout(request): logout(request) return HttpResponseRedirect('/home/')

Хотя приведенный выше код прост, это в основном то, как все будет сделано с любым многоразовым приложением?

Мой вопрос очень длинный, но я думаю, что эта проблема многоразового использования – это то, что многие разработчики не совсем поняли сами по себе, и, возможно, этот ответ поможет многим другим, которые слышали о обещаниях многоразовых приложений, но не могут понять, как их использовать.

TL; DR:

Нет, это зависит …

Некоторые (очень) обычные многоразовые приложения

django.contrib.admin
django.contrib.auth
django.contrib.staticfiles

… все это многоразовые Django-приложения, которые поставляются с Django (большинство из них не было, в какой-то момент времени)

Хорошо, некоторые другие многоразовые приложения, которые не поставляются с Django:

Джанго-отдых-рамка
Джанго регистрации
юг

Это все действительно многоразовые приложения, и не что иное. Подобных приложений очень много.

Как они это делают?

Для меня ваш вопрос больше похож на «как создать многоразовые приложения», а затем «как их использовать». Фактически использование их сильно отличается от приложения к приложению, потому что они делают совсем другие вещи. Существует только одно правило: RTFM. Ничего подобного .

Часто они полагаются на одно или несколько из следующего:

дополнительные значения в settings.py
добавление (обычно один оператор inlclude ) в urls.py
подклассы и / или mixins для моделей, форм, полей, представлений и т. д.
шаблонные теги и / или фильтры
команды управления
…

Все это мощные способы, которые ваше приложение может обеспечить функциональность для других приложений. Рецепт (AFAIK) не существует, чтобы сделать приложение многократного использования, потому что есть много разных сценариев. Все зависит от того, что именно должно делать ваше приложение.

Многоразовые приложения обеспечивают функциональность

Я бы сказал, что важно не думать о том, что многоразовые приложения «работают вместе» с другим приложением, но вместо этого признают, что они «обеспечивают функциональность». Детали предоставленной функциональности должны определять, как целевой разработчик должен использовать вашу библиотеку.

Не все должно быть повторно использовано

Очевидно, что даже несмотря на то, что многие приложения могут «в принципе» быть многоразовыми, часто не имеет смысла это делать, потому что быстрее скопиться вместе (и заставить их «работать вместе»).

Я не уверен, почему вы думаете, что вам нужно основное приложение для «frontend». Точкой многоразового приложения является то, что он заботится обо всем, вы просто добавляете (обычно) один URL-адрес, чтобы включить urls.py приложения, а также свои собственные шаблоны и стиль, если требуется.

И вам, конечно же, не нужно обертывать представления приложения в своих собственных представлениях, если вы специально не хотите переопределять некоторые функции.

Я вообще не понимаю ваш вопрос о моделях. Нет такой вещи, как «основной» файл моделей, а использование моделей многоразового использования – это то же самое, что использовать модели из любых ваших собственных приложений.

Обычно вы не редактируете стороннее приложение, поэтому очень сложно интегрировать обновления. Просто установите приложение в свой virtualenv (вы используете virtualenv, конечно!) С помощью pip, который поместит его в каталог lib, и вы сможете ссылаться на него так же, как и на любое другое приложение. Убедитесь, что вы добавили его в INSTALLED_APPS.