Что мешает вам использовать 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 и т. Д. - все, что вам может понадобитьсяimport.
Точно так же, если вы можете создать что-то вроде блога в формате, который является довольно общим для установок, вы можете обернуть его в приложении, с его собственным шаблоном, папкой статического содержимого и т. д., и настроитьэкземпляр проекта django для использования содержимого этого приложения.
Нет жестких и быстрых правил, согласно которым вы должны это делать, но это одна из целей фреймворка.Тот факт, что все, включая шаблоны, позволяет вам включать из какой-то общей базы, означает, что ваш блог должен плотно вписаться в любую другую настройку, просто заботясь о своей собственной части.
Однако для решения вашей реальной проблемы, даничто не говорит о том, что вы не можете работать с папкой проекта верхнего уровня. Это то, что приложения делают , и вы можете сделать это, если вы действительно этого хотите.Однако я склонен этого не делать по нескольким причинам:
- Настройки по умолчанию в Django этого не делают.
- Часто я хочу создать основное приложение, поэтому я создаю его,обычно называется
website.Однако позже я мог бы захотеть разработать оригинальную функциональность только для этого сайта.Чтобы сделать его съемным (независимо от того, делаю я это или нет), я обычно создаю отдельный каталог.Это также означает, что я могу отказаться от упомянутой функциональности, просто отсоединив этот пакет от конфигурации и удалив папку, а не сложное удаление нужных URL-адресов из глобальной папки urls.py. - Очень часто, даже когда я хочучтобы сделать что-то независимое, ему нужно где-то жить, пока я присматриваю за ним / делаю это независимым.По сути, это вышеупомянутый случай, но для вещей, которые я собираюсь сделать универсальными.
- Моя папка верхнего уровня часто содержит несколько других вещей, включая, помимо прочего, сценарии wsgi, сценарии sql и т. Д.
- расширения управления django основаны на подкаталогах.Поэтому имеет смысл называть пакеты соответствующим образом.
Короче говоря, причина, по которой существует соглашение, такая же, как и у любого другого соглашения - это помогает, когда речь идет о других, работающих с вашим проектом.Если я увижу fields.py, я сразу же ожидаю, что код в нем будет подклассом поля django, тогда как, если я увижу inputtypes.py, я, возможно, не пойму, что это значит, не глядя на него.