0x00 Why I popped out? 好久不写博客了，其实还是很喜欢在C++博客上面写东西的，轻量化的东西就是那么好用。现在也没心思贴什么OI题解的代码了，已然成为了练手练脑的工具，时不时做两道又想回去火拼了。一直想给自己挪个窝，话说server都弄好了，就是没尝试过自己写个博客，借着这学期database课程的机会，破天荒搞了一轮WebApp using db。 // 其实是老师的大作业 (/▽＼=) 以前也不是没有动过前端的开发，高三的时候HTML 5刚刚兴起，我就赶了一把时髦，现在canvas还让我大呼爽快。 好了，这篇还是一个随想录一样的东西，我要做的是一个表情分享的WebApp，然后架构挑的是Django，数据库用的是SQLite，因为在Windows下面比较友好一点，如果是Linux用啥都一样好。下面不系统地小结我遇到的问题，想到哪里说到哪里，可能也是很多人用Django的一个疑惑，毕竟关于它的博文人云亦云，而且用的版本参差不齐，搞得人都要爆炸。说到底，开源的东西，回归文档、邮件列表、文件。
0x01 Startproject 这里说下目录的安排。大体上一个Django做出来的东西会包含下面几个东西：project，apps，models，static files, etc. 所以从manage.py startproject开始就要对文件的布局有个比较清晰规划，至少我是这样的，因为Django的URL设计是特色，也就是说“找到”对Django很重要，tree了一下。如下图所示：
关于数据库模型的emodb App我放在根目录下面（Django约定，要使用数据库模型，必须建立一个App），静态文件目录static、HTML模板目录templates也放在根目录，关于views、settings、urls等和MTV模型的逻辑文件默认在与项目同名的文件夹下。在settings.py这个文件中，可以找到项目目录BASE_DIR： BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
上面的tree就是在BASE_DIR这个目录下面执行的结果。 然后说一句很重要的话，我用的Django版本是： >>> import django
>>> django.VERSION
(1, 8, 5, 'final', 0)
0x02 Templates
很多人要搞Django，一打开度娘搜索，结果会惊喜地得到一个中文版的DjangoBook，我也是从这里开始的，因为的确翻译得不错。然后说到Templates的时候，问题来了。
在工程文件下面有个setting.py，里面存了基本整个项目的配置文件，定义用了大量的Python变量和元组、类，层次挺清晰的。一般会把写的模板放到一个目录下面，便于管理，根据这个中文版的DjangoBook，会定义一个叫TEMPLATES_DIRS的元组，里面用字符串表达存储了html模板文件的路径用于render_to_response什么的渲染，一般还会用setting.py里的BASE_DIR来描述，BASE_DIR是os.path模块捣弄出来的项目路径。这么做的好处详见相对与绝对路径。但是定义了多次都发现找不到templates，或者说用get_template函数的时候，只能像下面这么写：
from django.template.loader import get_template
t = get_template('templates/raw.html')
再次确认了文档，Django在寻找自身文件的时候，都是从项目的目录开始的，也就是说按照上面这么写template目录，TEMPLATES_DIRS是无效的！所以我就在网上找了很多文章，可能是由于版本不统一的问题，都无法解决，最后还是硬着头皮去看文档，关于模板设置Templates，里面Configuration就写得很好，之前我也发现了TEMPLATES，也尝试添加了DIRS元组，却不成功，确认文档之后才去掉了templates目录名字，直接写HTML文件名。
模板设置变量的时候我发现一个问题仍然没有解决，这里也说一下。比如我要用{% for %}去做一个循环输出元素，希望每输出三次就换一次行，<br />，但貌似不支持运算符，尽管有forloop.counter在手。
0x03 Models, Database
有了Templates小节里面的教训之后，我就特别小心的看DjangoBookCn。 建立模型类，也就是数据库里的基本表，在Django里面是一种享受，因为可以用统一的Python做一次编程之后，直接移植到支持的四款数据库上面。
这个过程在DjangoBook中叫做syncdb、sqlall，看得我很是欣喜，然而并没有那么简单。如果在我使用的版本下，使用这两个命令会被提示如下（以syncdb为例）:
后面貌似也能运行，但是重点是warning，1.9版本的Django会移除，那么现在我们应该用什么呢？
查阅文档Models得到，为了更好的管理数据库模型的进度，貌似Django给models加入了一个小的VCS，migrate系统，对于新的数据库变动可以使用manage.py里的makemigrations来立flag，默认地对于每次一makemigrations，都会给一个ID，就像git的版本编码一样。然后使用manage.py migrate将改动与数据库同步。
再说下数据库，SQLite在settings.py定义是最简单的，因为不涉及访问控制什么的，默认情况下，SQLite的数据库文件会是一个db.sqlite3文件（在我的版本下 (●'◡'●)），我在实验阶段，就注意到了这问题。这个不必强求改成db格式，因为一样，用sqlite3打开之后都能正常使用，默认第一次runserver之后，会发现里面只有一个表，django_migrations。0x04 Staticfiles 在Django里面还有一个重要的事情就是静态文件，我这里把用户上传的源图片也当成静态文件放到static目录下了。图片的存储我还是觉得应该用实体文件+数据库存url的方式比较好，只是要给那个图片库的目录加访问控制，那是server端应该做的考虑，这里因能力不足，无法赘述。然后就是静态文件的使用了，其实还是模板的变量，比如CSS的link。 {% load staticfiles %}
<link rel="stylesheet" type="text/css" href="{% static "css/universe.css" %}" />
<link rel="stylesheet" type="text/css" href="{% static "css/home.css" %}" />
0x05 Team Structure
最后说下，团队结构的问题，这个问题在我到大学以来就没有很好的解决。这次项目层面也不例外，但是整体来说还是很成功的组织。// 毕竟是两个女生，靠谱。(/▽＼=)
由于Django是松耦合的，就像JavaScript、HTML、CSS那样的关系，决定了最唾手可得的一个团队模型，就是templates得有专人写，包不包含设计看人手和能力；
views和urls要专人写，最好views分成模块，分给不同的人，urls可以说是Django很精髓的一个地方，也就是可以堪称艺术的地方，其实也没什么big deal，正则过关就行。
然后其他的测试什么的，用户体验什么的都是呃，大作业里说的酱油？好吧，没有他们你的数据库里空空如也。
至于为何选Django，没有选玩一样的Asp.NET，请看官网标题，The web framework for perfectionists with deadlines.
请多指教，多多交流 (●'◡'●)
posted on 2015-11-12 11:30
molasses 阅读(1385)
评论(0) 编辑 收藏 引用