Я предполагаю, что в более традиционном подходе дизайнеры пользовательского интерфейса и серверные разработчики работают на двух концах спектра разработки и, надеюсь, доброжелательно сходятся где-то посередине.Если вы захотите испачкать руки написанием нескольких строк кода, вы можете выложить всю архитектуру приложения для разработчиков, потому что у вас есть преимущество - ваше непосредственное отношение к пользователям, данным, которые они потребляют, ивзаимодействия, которые они должны выполнить.Это отнимает у разработчиков большую часть догадок, теперь нужно только заполнить дыры, соединить точки или что у вас есть.
Первое, что вы должны сделать, это собраться вместе и установить некоторые общие основания.,Как правило, это включает в себя выполнение модульности в самом начале.Возьмите все основные функции и разбейте их на несколько приложений Django, которые собираются обернуть шаблон, просмотреть и моделировать триады, относящиеся к определенной функции, предоставляемой приложением.Чем больше, тем лучше здесь, так что не беспокойтесь, если у вас будет много приложений, потому что вы никогда не захотите иметь одно приложение, предоставляющее слишком много функций / размещающее слишком много компонентов.Обычно вы начинаете с приложений, таких как registration, authentication, profiles (пользователь), и работаете дальше.Например, вы можете втиснуть все три в одно приложение, но в итоге у вас будет много шаблонов, множество представлений, возможно, две или три модели, но тесты действительно станут серьезной проблемой.Итак, разбейте все на эти блоки приложений, пока не почувствуете, что каждая часть системы естественным образом встает на свои места на концептуальном уровне.Если вы когда-нибудь задумывались над тем, где что-то разместить, или вы смотрите на модуль длиной в несколько страниц и испытываете желание разбить модуль (models.py, views.py, test.py) на пакет с множеством внутрипакетных пакетов.модули, вы, вероятно, должны немедленно изменить архитектуру.Всегда помните, что ваши усилия направлены на то, чтобы поразить вашу архитектуру простотой.
Как только это будет сделано, вы действительно выполнили половину работы.Отличительной особенностью Django является то, что у вас слабая связь между URL-адресами и представлениями.Сами представления обеспечивают поведение приложения и упрощают представление.Если вы можете правильно выложить основные URL-адреса и заглушить представления, просто создавая статические шаблоны, вы только что проделали хорошую работу.
Вот как это достигается.Вы можете абстрагировать URL-адреса и представления, на которые они отображаются, назвав свои шаблоны, такие как authentication:login, authentication:logout, registration:register, registration:confirm, registration:activate и т. Д. Таким образом вы привязываете свои внутренние компоненты ко всемпредоставляемое поведение, которое не должно меняться.Затем вы всегда можете изменить шаблон URL для authentication:login, изменить представление, на которое отображается шаблон, но вы ссылаетесь на него по внутреннему имени, так что вы можете, скажем, поменять представления, которые только что произвели статические шаблоны, на полную мощность.просматривать без каких-либо дополнительных изменений в вашем коде.
Итак, вот как это работает в реальной жизни:
- Мозговой штурм, выберите приложения и функции, которые они будут предоставлять, ипересмотрите свои решения.
- Начало работы с приложением
core, в котором будут размещаться некоторые специфические для проекта функции, такие как базовые шаблоны и представление / root. - Создание
/core/templates/core/base.htmlон будет загружать все распространенные файлы CSS / JS, которые будут использоваться для всего сайта, которые будут определять разделы верхнего и нижнего колонтитула (блоки шаблона), и который будет использовать контекстные переменные для метаданных страницы, такие как заголовок, описание, ключевые слова и роботы.Ваш типичный «один шаблон для управления всеми», биты, которые будут присутствовать в структуре / представлении для всех ваших страниц. - Создайте простое
/core/temaplates/core/welcome.html, которое расширяетсяосновной шаблон и принты "Hello world!"в области содержимого. Добавьте следующее к /core/urls.py:
from django.conf.urls.defaults import *
from django.views.generic import TemplateView
urlpatterns = patterns('',
# Welcome
url(
r'^$', TemplateView.as_view(template_name='core/welcome.html'),
name='welcome'
),
)
Подключите его в основном /urls.py:
from django.conf.urls.defaults import *
from django.contrib import admin
admin.autodiscover()
urlpatterns = patterns('',
url(ur'^', include('core.urls', namespace='core')),
url(ur'^admin/doc/', include('django.contrib.admindocs.urls')),
url(ur'^admin/', include(admin.site.urls)),
)
Нажмите http://localhost:8080/, см. «Hello World!», Наслаждайтесь теплым нечетким ощущением.
- Повторите то же самое для остальных приложений: создайте приложение, создайтешаблоны, присвойте им имена, сопоставьте их со статическим шаблоном, подключите его к пространству имен в главном
urlconf.
Вы можете продвинуть представления еще дальше к готовности к работе для разработчиков.Это может зависеть от разработчиков и их руководств по стилю, но мне нравится держать мой /urls.py в чистоте от всего, кроме шаблонов, имен и отображений.Ваш /core/urls.py может выглядеть следующим образом:
from django.conf.urls.defaults import *
from core import views
urlpatterns = patterns('',
# Welcome
url(
r'^$', views.Welcome.as_view(),
name='welcome'
),
)
Редактировать /core/views.py со следующим:
from django.core.views.generic import TemplateView
class WelcomeView(TemplateView):
template_name='core/welcome.html'
extra_context={
'page_title': 'Welcome!',
'page_keywords': 'relevant,page,keywords',
'page_description': 'Something equally relevant',
}
def get_context_data(self, **kwargs):
context = super(WelcomeView, self).get_context_data(**kwargs)
context.update(self.extra_context)
return context
И это один надежный и компактный вид, заполненный метаданными страницы!Определенно материал, который принесет вам пиво от разработчиков.Продолжайте делать это для всех представлений, чтобы выкачать статические шаблоны.Когда кто-то подходит к завершению представлений, ему просто нужно унаследовать от другого класса представлений, добавить недостающие функции, расширить контекст, изменить шаблон и вуаля - он готов к производству.
Там нетвам понадобится много предварительных знаний, чтобы сделать это возможным, но это действительно отнимает много догадок для разработчиков, которые, естественно, больше заботятся о создании остальной части приложения.Это также достаточно просто, чтобы стать действительно хорошим, я думаю, никто не возражает позволить вам делать всю эту работу.Как добавлено, вы, вероятно, не будете в курсе того, как контекст шаблона заполняется в представлениях, поэтому даже вы можете начать развертывать более сложные представления или, по крайней мере, иметь возможность их читать.