Що зупинити вас на використанні 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я не можу бути зрозумілим, що це означає, не дивлячись на нього.