Что мешает вам использовать myproduct.myproduct? То, что вам нужно для этого, примерно состоит в следующем:
django-admin.py startproject myproduct
cd myproduct
mkdir myproduct
touch myproduct/__init__.py
touch myproduct/models.py
touch myproduct/views.py
и так далее. Поможет ли это, если я скажу, что мне views.pyне нужно звонить views.py? При условии, что вы можете назвать в пути python функцию (обычно package.package.views.function_name), с которой она будет обрабатываться. Просто как тот. Все эти "проекты" / "приложения" просто пакеты Python.
Теперь, как ты должен это сделать? Или, скорее, как я могу это сделать? Ну, если вы создаете значительную часть многоразовой функциональности, как , скажем , редактор разметки, это при создании «приложения верхнего уровня» , которые могут содержать widgets.py, fields.py, и context_processors.pyт.д. - все вещи , которые вы могли бы хотеть импорт.
Точно так же, если вы можете создать что-то вроде блога в формате, который является довольно общим для установок, вы можете обернуть его в приложении, с его собственным шаблоном, папкой статического содержимого и т. Д., И настроить экземпляр проекта django для использования этого содержание приложения.
Нет жестких и быстрых правил, говорящих о том, что вы должны это делать, но это одна из целей фреймворка. Тот факт, что все, включая шаблоны, позволяет вам включать из какой-то общей базы, означает, что ваш блог должен вписаться в любую другую установку, просто заботясь о своей собственной части.
Тем не менее, для решения вашей реальной проблемы, да, ничего не говорит, что вы не можете работать с папкой проекта верхнего уровня. Это то, что делают приложения, и вы можете сделать это, если действительно хотите. Я, как правило, не по нескольким причинам:
- Настройки Django по умолчанию этого не делают.
- Часто я хочу создать основное приложение, поэтому я создаю его, обычно называемое
website. Однако позже я мог бы захотеть разработать оригинальную функциональность только для этого сайта. Чтобы сделать его съемным (независимо от того, делаю я это или нет), я, как правило, создаю отдельный каталог. Это также означает, что я могу отказаться от упомянутой функциональности, просто отсоединив этот пакет от конфигурации и удалив папку, а не сложное удаление нужных URL-адресов из глобальной папки urls.py.
- Очень часто, даже когда я хочу сделать что-то независимое, ему нужно где-то жить, пока я за ним присматриваю / делаю это независимым. В основном вышеприведенный случай, но для вещей, которые я намерен сделать обобщенным.
- Моя папка верхнего уровня часто содержит несколько других вещей, включая, помимо прочего, сценарии wsgi, сценарии sql и т. Д.
- Расширения управления django опираются на подкаталоги. Поэтому имеет смысл называть пакеты соответствующим образом.
Короче говоря, причина, по которой существует соглашение, такая же, как и у любого другого соглашения - это помогает, когда дело касается других, работающих с вашим проектом. Если я увижу, fields.pyя сразу ожидаю, что код в нем подклассирует поле django, тогда как, если я увижу, у inputtypes.pyменя может быть не совсем понятно, что это значит, не глядя на него.