我的第一个Django应用

业余时间自学Python，通常都是做些简单的文本替换、查找和简单的shell脚本。之前都是用bash和perl。bash的功能弱了点儿，perl的语法太难记，都放弃了。遇到python后发现上手很容易，功能比较强，挺喜欢的，就一边用一边学，断断续续也有3年了。（惭愧，3年了还徘徊在入门水平 :oops: ）

第一个稍微像样点儿的python程序，是一个嵌入式项目的daily build脚本。当时项目的编译比较花时间，大概需要半个小时才能编译完。再加上生成image的环境也比较复杂，需要一个能自动编译和生成image的工具。那会儿刚看完Learning Python，对Python还没啥感觉，基本上是把以前写bash脚本的方法，直接搬过来写。现在看来，那代码是惨不忍睹了。不过当时是比较满意的，因为能很正常的完成任务。那个工具一直正常服役到整个部门被解散掉。

接下来开始对wxPython发生兴趣。这时正好碰上组里头有人有一个小小的需求，需要把大量的GPS数据导成KML文件。说白了，也就是很简单的文本解析和KML文件生成，拿python做这个太easy了。正好对wxPython也一知半解，拿来练手不错。于是东拼西凑的，弄出了一个GUI版的工具，没想到竟然挺受欢迎的。于是需求不断涌来，几个型号产品生成的数据（格式相差还挺大）都有相同的需要，大家都说去，找他要个工具。

用的人多了，麻烦也来了。组里就我一个人用python，不可能让每个人都装一套python的环境吧，人家就要一个小工具，你动辄就要人家装个几十MB的软件，大家都麻烦。这时想的第一件事就是怎么能轻松发布。Google了一番后，找到了py2exe，直接把python的程序和所需的环境转成windows下可发布的东西。600来行的代码要发布近15M的东西，虽然不太满意，但终归比较方便了。

没多久，麻烦事儿又来了。数据生成端随着项目的进展在不断变化，我这工具也要跟着不断更新。怎么把更新后的软件丢给使用工具的人呢？总不至于为了这么小个软件搞个自动升级吧。说来也是机缘巧合，正巧这时开始对web发生兴趣，如果把这个工具搞成web app，就可以解决这个问题了。随便Goolge一下，一大堆推荐Django的文章，都说上手如何之快，功能如何之强，甚至于搞个视频20分钟给你建一个blog应用出来，那是相当的诱惑啊。于是找了本Django的书（也巧，那时正好Django的第一本中文书也出版了），翻了一遍，虽然基本没动手，但是看起来确实是比较适合我这种水平和需求。

工具定下来了，接下来就是动手了。目标明确，步骤也不复杂。只要将原来的桌面GUI的东东转成web界面，底下解析和文件生成的部分，变化基本不大。知易行难，前前后后也花了10个工作日，呵呵，远不像人家20分钟搞定一个blog那么轻松。但从最后的结果来看，Django的确是个很棒的东东。如果你像我一样，只会一点点Python的基本语法，从来没有做过web开发，仅仅了解一点html和极少的css，Django会给你一双翅膀。

整个工作大致分为几个阶段：
[list=1]
[*]建立数据模型和视图。
[list]
[*]因为目标比较简单，需要保存在数据库里东西很少，而且关系简单明确（many to many）。因此数据模型只要处理很简单的东西就好，启用Django的admin后，已经可以满足我的需要。
[*]这一阶段主要纠结在如何使用form，如何将原GUI选项转换成web的form，怎样处理post数据。
[/list]
[*]处理文件上传。对于desktop版，这个比较简单，只要简单的读取文件操作就好。转到web后，当文件很大的时候，数据会分段传进来。因此这一阶段主要花时间在文件拼接和分段解析处理。
[*]页面布局和美化。由于没有什么web开发经验，css也不大懂。这个阶段基本就是照抄Django官网的css和页面布局 :D 。按照输入数据和输出数据，修改模板。
[*]发布。在开发环境下都调试好后，发布竟然用了整整一天。基本上问题都出在代码中使用了相对路径，最后都改成了绝对路径。另外就是在apahce中处理一些静态文件的发布。
[/list]

总的来说，这次试用Django的过程还是蛮令人兴奋的，结果也还不错。对于web开发，Django确实是个不错的工具。