真是一个振奋人心的消息,Django终于要结束三年以上的版本长跑,出1.0版了.苦了社区里面的朋友,一直在苦苦等待.
这次发布的直接原因估计是前段时间Django易主,由新的基金会支持Django的发展.
本站是基于django开发D,当时的版本还是0.96,大概在去年9月份上的线,等到1.0正式版出来,马上就升级啦!
期待Django的正式版早日发布,期待更多的朋友加入django的行列.
最近一直断断续续地给本系统做更新。由于时间关系，进展比较慢。这一次的更新主要是把后台管理界面重新设计，狠狠地补习了一顿DIV + CSS；还有就是使用上的Ext2.0。Ext和Json交互真的好处多多，在客户端对数据的操作确实非常方便。稍晚的时候将会整理一份Ext的使用心得。下面来些截图，尽管效果不太好 ：）。原图太大撑破了布局，麻烦有兴趣的同学点击看大图吧，对不住了。
第一个图：后台主要的风格和Ext的表格。Blogger，WordPress都使用这样的导航菜单，我实在没其他好主意，就依葫芦画瓢了。用Django自定义标签来生成导航还是挺有意思的。
第二个图：分类管理的截图，使用Ext的可编辑表格做D。前后台数据交换方便快捷，爽歪了。
最后一个图了：写文章的截图，FCK的工具栏简化了，并且改用了Office的样式，看起来和总体的蓝色更协调一些。
秀完了。这一次的更新里面只使用了Ext的表格控件，接下来改造设置等功能的时候试一下它的Form控件和Django的Newform。
啊？这个界面让你想吐吗？真抱歉，我有空再继续深造我的CSS去吧。
本文描述的是本站的分页方案。
由于分页功能在列表的地方通常会用到，所以最理想的分页方案实现应该是使用简单、可重用性高的。正如我希望在显示一个分页信息是通过下面的代码来实现：{% page_info datas '/blog/xxx/' %}。有一个名字叫Page的标签，接受两个参数，第一个参数是分页信息、数据（数据按需要来决定是否要），第二个参数是列表的URL。使用标签的目的是避免重复写相同的分页HTML代码。
着先，设计一个Pager类，该类存放分页相关信息：数据总数、当前页码、页码大小、上一页、下一页、首页、最后一页等，还有一个Datas属性供保存真实的数据，该属性应该是一个集合。下面来看看该类的代码：
Django的自定义标签除了基本的（也是经典的）标签定义之外，还提供了更方便的标签定义功能，包括我正在使用的Inclusion Tag。参考文档见这里：http://www.djangoproject.com/documentation/templates_python/#inclusion-tags。通过这种方式定义一个标签很简单。只需要用标签名写一个方法，然后注册到标签库就可以了。可以把标签的使用想象成方法的调用，本站的标签看起来是这样的：
page_info 函数就是标签的处理函数，要求返回的是一个字典。这些字典里的值将作为上下文传到将要被Include的模板中，即Common/pagination.html。
自定义标签需要注意的一个地方：总是要把标签定义的程序文件放在App的templatetags目录下，在模板加载自定义标签的时候Django除了加载默认的还会到每个App的temlatetags目录下加载。
这样，标签定义好了，最后剩下要做的是完成我们的分页模板：
这些已经是分页模板的全部代码。当然，为了使用分页功能，某些列表的代码需要作相应的改动，包括使用上面定义的Pager类。
我是这样使用这个标签的：
本博客的程序好久没有动刀，今天晚上动起手来真是慢到抽筋（慢到要命）。写一个分页的标签折腾了半天。最后总算能交货。效果请看本博客的文章列表。目前展现方面还有点简陋，不过设计上已经支持前台各种展现方式。如1234567一样展开页码、用户输入页码跳转等。
看看时间，已经远远超过我所谓的早睡的界限了。详细的步骤明天再写一遍。
洗澡的时候想起JSP内置的Include标签，也想起Django内置的Extend标签，两者的实现是完全相反，但是在某些情况下使用Extend可以获得很大程序的灵活，至于JSP的Include标签的效果，Django已经支持－－我的分页标签说白了就是一个Include。我在脑海中寻找有没类似Extend这样的jsp标签，Sitemeth不是，尽管他配置很少，但那一长串Exclude看见就恶心，Tiles更不用说。如此看来，自己开发一套Extend的标签也未尝不可，完全零配置，需要的时候才用。
所谓的Extend机制，想想类继承机制就清楚了。子类直接获得父类的东西，在页面上，子页面直接获得父页面所有内容，而且子页面可以重写（Override）某一个块的内容。Django的模板就是这么做的，Jsp如果也有这样一套Tag，那就可以抛掉那些所谓的装饰器了，一个Include一个Extend相当一开一合，妙。
有时间按Django的模板机制写一套标签玩玩，Maybe Jsp，也可能其他模板语言。
抛弃原有用户模型、使用Django的用户、权限模型。数据迁移平稳，移植成功。涉及修改的有View，Decolator以及部分Template。
TODO是加上UserProfile，以及开始考虑帮捞捞把家搬到这里。还有最好可以加个手机日志，好让俺在旅游的时候可以。。嘿。。
中间件的名堂听起来很大。但在Django里面，中间件实际上就是一个过滤器（像Java的Servlet里面的Filter）。如果你需要在一个请求到来之后、View函数调用之前、在响应给客户端之前和View函数抛出异常的时候做些什么事情，那么你可以自己写一个中间件。
Django中间件必须是一个类，并实现四个接口，也就是必须提供四个方法：
process_request(self, request)，只有一个请求作为参数，该方法在请求到来的时候调用。
process_view(self ,request, fnc , arg ,kwarg)，在本次将要执行的View函数被调用前调用本函数。第一个参数为请求，二为将要执行的View函数实例，arg与kwarg分别为参数元组及参数字典。
process_response(self,request,response),在执行完View函数准备将响应发到客户端前被执行。
process_exception(self,request, exception). View函数在抛出异常时该函数被调用，得到的exception参数是实际上抛出的异常实例。通过此方法可以进行很好的错误控制，提供友好的用户界面。
官方指南：
一、中间件不需要继承任何类
二、你的中间件可以放在任何一个地方，当然前提是在Python的Path当中。Django只要在settings.py的MIDDLEWARE_CLASSES中找到它就可以了。
三、可以参考Django现有的中间件。
四、如果你写了些有用的中间件又觉得可以给其他人用，欢迎提交到Django，Django将考虑把它加入项目。
又遇到了灵异事件。。Django的ORM。orz.
昨天对Blog的程序进行了优化。见前一篇文章，因于文章分类允许为Null导致查询文章列表时（列表需要显示分类名）Select_related不起作用引发了1+N问题，所以我把Null=True去掉。减却了多余的N条查询。但是奇怪的事情发生了，我从早上开始发觉，首页列表的作者变成了Blog的Title。但代码明明是{{entry.author.name}}！我改成其他属性试下，依然是Print出Blog的其他属性。我回想昨天更新做过的改动，撒销均无效。最后想起会不会是因为改了Model的属性引起的，于是我把分类的Null=True加上。果然！显示正常了。这是为什么呢？不解！缓存？没可能吧？
我是不可能再把分类的Null=true保留的，因为实践证明这样对性能损耗太大。但不加上又出现属性值错乱的情况。怎么办？最后我作了个尝试，我把Model里面的属性调换了一下位置，原来Author在Catelog下方:
catelog = models.ForeignKey(Catelog,verbose_name='分类')
author = models.ForeignKey(Account,verbose_name='作者')
现在改回来，Author写在Catelog上方。显示正常。My god!
author = models.ForeignKey(Account,verbose_name='作者')
catelog = models.ForeignKey(Catelog,verbose_name='分类')
这是我的程序的Bug？还是Django的Bug？还是我的Bug？我想这个解决的办法不是好办法。
我拿到三种情况的Sql。一是分类为Null的查询，二是分类为NotNull的查询，三是分类为NotNull且Author属性排在Catelog前面的查询。结果是第一和第三种情况blog_account_name所在的列位置是一样的。这是否说明Django的确是记住查询结果的位置并且缓存起来了？但缓存到哪里了呢？如果刷新呢？
OK Computer!
