posts - 6,comments - 4,trackbacks - 0
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 阅读(1369) 评论(0)  编辑 收藏 引用

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理