学子天地场地申请网站设计问题总结
2014-06-22 22:15
288 查看
场地申请代码
由于深大各组织经常要使用校内场地,为了规范各组织使用校内场地,避免使用时间冲突,校团委需要一个系统来管理校内场地的使用。
旧场地申请系统投入使用很多年,之前一直还算稳定,但上一年开始经常出现一些莫名其妙的问题,加上代码实在太乱,所以我就用django重写了。
整个场地申请,功能简单来说就是:各个使用场地的组织在使用场地前先在网上提交使用申请,得到管理员的审批后,该组织可以在管理员拿到使用场地的凭证,方可使用场地,所有申请和审批,都在这个系统上公示。
麻烦的地方是,这个系统需要实现多样而又多变的的申请和审批规则。而且我现在的设计做得很死,都是贴着框架来实现,产生很多问题。
本文将剖析每个细节的设计问题,希望能对学子后人有帮助。篇幅较长。
首先最大的问题是,现在我根据四个场地(学活,会议室,露天场地,展览场地) 分成了四个app来做。但是,由于他们的逻辑本质上是一样的,现在4个app几乎用的是同样的代码(仅仅是部分细节不一样)。当我需要改一个地方的时候,要同时改4份,非常麻烦而且很容易出错。
几乎所有的问题,都是从模型层的错误设计开始的。
那时候团委催得很急,我们都希望能够快速完成这个系统,于是直接仿照旧系统开发。旧系统四个场地 (包括南区运动场,现在没了,但是现在把以前的校园场地拆成露天场地和展览场地),对应四组功能几乎相同的页面,包括
1.提交,修改申请表的页面
2.分别以表格和列表的方式公示已提交的申请和审批情况的页面
于是仿照旧系统,我很自然地根据申请表设计出模型层。 具体见 场地申请代码 campus_field, meeting_room, student_activity_center 里面的models.py
存储申请内容的数据表就只有一张,完全跟用户填写的表单对应。在此基础上,完成了控制器和视图层。(每个app的views.py放控制器代码)
比较四个app的控制器,可以看到他们的代码几乎是一模一样的!都包括
1. ApplyView 处理提交表单
2. display_table 将申请数据以表格形势展示到页面,实际生成表格结构的代码放在了models.py
3. generate_page 用来生成page对象,不是控制器
4. ListAppView 以列表形式展示已提交的申请
5. ManageView 以列表形势展示自己的申请,在这里页面可以点击链到修改申请的页面
6. get_detail 处理ajax,接受一个对应申请的id,返回对应这个id的申请的基本信息
7. ModifyView 处理修改申请
8. delete 删除申请
9. manage_approve 处理管理员通过审批的请求
既然他们代码都差不多,那他们不同的地方在哪里呢?是什么让他们不能写成同一份,而要拆成四份?
先来看ApplyView,下面是学活的
class ApplyView(View):
@method_decorator(login_required)
def get(self, request):
return render(request,
'student_activity_center/form.html',
{'form': StudentActivityCenterApplicationForm(),
'post_url': reverse('student_activity_center:apply')})
@method_decorator(login_required)
def post(self, request):
form = StudentActivityCenterApplicationForm(request.POST,
request.FILES)
if not form.is_valid():
return render(request, 'student_activity_center/form.html',
{'form': form,
'post_url': reverse('student_activity_center:apply')})
app = form.save(commit=False)
app.organization = request.user.organization
app.save()
return HttpResponseRedirect(reverse('student_activity_center:manage'))
它跟其他场地不一样的有
1. form 使用的是StudentActivityCenterApplicationForm
2. template文件不同
3. 由于四个场地的申请页面使用的是同一个template文件,所以要传一个post_url 到 template 表单的action字段来告诉表单给哪个场地的控制器提交请求
4. 提交成功后返回的页面url
对于这些不同,我首先想到的是将这些不同的地方参数化,可以通过一个工厂函数接受参数然后返回这个class来实现。但是还是有问题,一旦需要修改活增加新功能,那这些参数也需要跟着改变。而且一旦出现不能参数化的差异,这种方法就行不通。
template文件不一样,是因为各个场地的申请表字段不一样。post_url不一样,是因为处理不同场地申请的控制器不一样。提交成功后返回的页面不一样,是因为管理不同场地的申请的管理页面不一样。
其实管理页面完全可以4个合并成1个来做。这样的话,只要控制器使用的form是不区分场地的,
由于深大各组织经常要使用校内场地,为了规范各组织使用校内场地,避免使用时间冲突,校团委需要一个系统来管理校内场地的使用。
旧场地申请系统投入使用很多年,之前一直还算稳定,但上一年开始经常出现一些莫名其妙的问题,加上代码实在太乱,所以我就用django重写了。
整个场地申请,功能简单来说就是:各个使用场地的组织在使用场地前先在网上提交使用申请,得到管理员的审批后,该组织可以在管理员拿到使用场地的凭证,方可使用场地,所有申请和审批,都在这个系统上公示。
麻烦的地方是,这个系统需要实现多样而又多变的的申请和审批规则。而且我现在的设计做得很死,都是贴着框架来实现,产生很多问题。
本文将剖析每个细节的设计问题,希望能对学子后人有帮助。篇幅较长。
首先最大的问题是,现在我根据四个场地(学活,会议室,露天场地,展览场地) 分成了四个app来做。但是,由于他们的逻辑本质上是一样的,现在4个app几乎用的是同样的代码(仅仅是部分细节不一样)。当我需要改一个地方的时候,要同时改4份,非常麻烦而且很容易出错。
几乎所有的问题,都是从模型层的错误设计开始的。
那时候团委催得很急,我们都希望能够快速完成这个系统,于是直接仿照旧系统开发。旧系统四个场地 (包括南区运动场,现在没了,但是现在把以前的校园场地拆成露天场地和展览场地),对应四组功能几乎相同的页面,包括
1.提交,修改申请表的页面
2.分别以表格和列表的方式公示已提交的申请和审批情况的页面
于是仿照旧系统,我很自然地根据申请表设计出模型层。 具体见 场地申请代码 campus_field, meeting_room, student_activity_center 里面的models.py
存储申请内容的数据表就只有一张,完全跟用户填写的表单对应。在此基础上,完成了控制器和视图层。(每个app的views.py放控制器代码)
比较四个app的控制器,可以看到他们的代码几乎是一模一样的!都包括
1. ApplyView 处理提交表单
2. display_table 将申请数据以表格形势展示到页面,实际生成表格结构的代码放在了models.py
3. generate_page 用来生成page对象,不是控制器
4. ListAppView 以列表形式展示已提交的申请
5. ManageView 以列表形势展示自己的申请,在这里页面可以点击链到修改申请的页面
6. get_detail 处理ajax,接受一个对应申请的id,返回对应这个id的申请的基本信息
7. ModifyView 处理修改申请
8. delete 删除申请
9. manage_approve 处理管理员通过审批的请求
既然他们代码都差不多,那他们不同的地方在哪里呢?是什么让他们不能写成同一份,而要拆成四份?
先来看ApplyView,下面是学活的
class ApplyView(View):
@method_decorator(login_required)
def get(self, request):
return render(request,
'student_activity_center/form.html',
{'form': StudentActivityCenterApplicationForm(),
'post_url': reverse('student_activity_center:apply')})
@method_decorator(login_required)
def post(self, request):
form = StudentActivityCenterApplicationForm(request.POST,
request.FILES)
if not form.is_valid():
return render(request, 'student_activity_center/form.html',
{'form': form,
'post_url': reverse('student_activity_center:apply')})
app = form.save(commit=False)
app.organization = request.user.organization
app.save()
return HttpResponseRedirect(reverse('student_activity_center:manage'))
它跟其他场地不一样的有
1. form 使用的是StudentActivityCenterApplicationForm
2. template文件不同
3. 由于四个场地的申请页面使用的是同一个template文件,所以要传一个post_url 到 template 表单的action字段来告诉表单给哪个场地的控制器提交请求
4. 提交成功后返回的页面url
对于这些不同,我首先想到的是将这些不同的地方参数化,可以通过一个工厂函数接受参数然后返回这个class来实现。但是还是有问题,一旦需要修改活增加新功能,那这些参数也需要跟着改变。而且一旦出现不能参数化的差异,这种方法就行不通。
template文件不一样,是因为各个场地的申请表字段不一样。post_url不一样,是因为处理不同场地申请的控制器不一样。提交成功后返回的页面不一样,是因为管理不同场地的申请的管理页面不一样。
其实管理页面完全可以4个合并成1个来做。这样的话,只要控制器使用的form是不区分场地的,
相关文章推荐
- 网站架构中分层设计总结1--解决的问题
- 多语言网站设计需要注意的问题
- .NET2005网站发布问题总结
- IIS6架设网站的问题总结
- J2EE大型网站架构设计一点总结
- J2EE大型网站架构设计一点总结
- 关于网站设计的整体设计步骤的总结
- 大型网站的架构设计问题----大型高并发高负载网站的系统架构
- 大型网站的架构设计问题----大型高并发高负载网站的系统架构
- IIS6架设网站过程常见问题解决方法总结
- 企业网站权限设计实现:问题修复
- 网站设计中程序员和美工的配合问题
- [置顶] 大型网站的架构设计问题----大型高并发高负载网站的系统架构
- 在做一个小网站的一些心得与遇到的问题总结,为以后方便查阅。
- 东方有线项目分析设计阶段遇到的问题及总结
- 2006网站设计风格总结分析
- 用户友好的,网站设计方式总结
- [置顶] 大型网站的架构设计问题----大型高并发高负载网站的系统架构
- 网页设计-[常用CSS缩写语法总结、标准的N种死法及网页设计必须注意的几个问题 ]
- ASP.NET网站设计的安全问题【转】