我想在更传统的方法中,UI 设计师和后端开发人员在开发范围的两端工作,并希望以一种优雅的方式在中间的某个地方融合。如果您愿意亲自编写几行代码,您可以为开发人员布置整个应用程序架构,因为您占了上风——您直接关心用户、他们使用的数据以及他们需要执行的交互。这将消除开发人员的大部分猜测,现在只需填补漏洞,连接点或你有什么。
你应该做的第一件事是聚在一起,建立一些共同点。通常,这包括在一开始就执行模块化。将所有主要功能分解为几个 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
,例如基本模板和根/
视图。
- 创建一个
/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!”,陶醉在温暖的模糊感觉中。
- 对其余的应用程序重复相同的操作:创建应用程序,创建模式,命名它们,将它们映射到静态模板,将其挂接到 main 中的命名空间
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
这是一个坚固的存根视图,包含页面元数据!绝对是那些能让你从开发者那里赢得啤酒的东西。继续对所有视图执行此操作以抽出静态模板。当有人接近完成视图时,他们只需要从不同的视图类继承,添加缺少的功能,扩展上下文,修改模板,瞧——它已经准备好投入生产了。
There's not a lot of upfront learning you'd have to do to make this possible, but it really takes out a lot of the guesswork for devs, which are naturally more concerned with building the rest of the application. It's also simple enough to get really good at, I would guess no one would mind letting you do all of this work. As added beef, you'll probably not be kept in the dark as to how the template context gets populated in the views, so even you can start rolling out more complex views, or at least be able to read them.