LBForum分裂为两个项目
最初写LBForum的时候为降低部署的难度，将LBForum作为完整的Django站点来进行开发。
实际应用过程中，不少人需要将论坛模块集成到已有系统中。
原有的方案在集成的时候有不少的问题。
而且整站的形式也不利于他人进行协作，若改动偏向站点的定制，会给代码合并的时候带来很大的问题。
在项目拆分后，在保证易部署特性的同时解决了第三方系统集成的问题。
LBForum是我用python（django）开发的一个开源的论坛系统。
更多的信息可以参考我以前写的博客 发布一个Django的论坛系统LBForum（开源、带演示）。
最近LBForum也终于有了一位活跃用户，也非常感谢他给我提出了不少改进的意见。他们是一个游戏汉化组织，网址是 http://bbs.tuidao.org/ 。
LBForum现在主要具备的功能有：
在我看来LBForum在功能方面已基本完善，对于LBForum以后的发展，目前还没有什么比较详细的计划。目前最缺的可能还是文档，只是一直没有什么动力去完善。功能方面也有些想做的，不过也是因为缺乏动力所以没太动手。
文档
功能
LBForum 用django开发的论坛系统，演示地址为：http://vik.haoluobo.com/lbforum/
项目的地址为：http://github.com/vicalloy/LBForum
界面部分抄的 FluxBB(一个开源的PHP论坛 http://fluxbb.org/ )。
虽然Django写的论坛也不少，不过还真没什么好用的。
大多Django论坛都是独立的app，而且不少还缺模板，想我这样有经验的Django用户要跑起来都觉得麻烦，其他普通用户就更别说了。
LBForum主要注重部署的方便性和易用性，功能方面目前还比较简单。
LBForum一开始就是以整站的形式提供，所以以LBForum做为基础项目进行二次开发是很容易的。
同时LBForum的开发尽量遵照Django可复用app原则，因此即使需要将LBForum做为独立的app集成到其他项目也并不会太难。
目前功能还比较简单，而且还有些小问题有待修正。
|+lbforum_env/#lbforum运行的python虚拟环境，运行create_lbforum_env.py后自动创建
|+requirements/#lbforum用的第三方库和app，运行的时候会将该目录加到python路径
|~scripts/#工程相关脚本
| |-create_lbforum_env.py#初始化python虚拟环境，并自动安装easy_install/django依赖库
| |-helper.py#提供其他脚本所需的辅助函数
| `-lbforum_env.bat*#启动lbforum运行的虚拟环境及，并为lbforum的manage.py提供快捷方式%mg%，比如初始化数据库%mg%
syncdb
|~sites/#站点配置/模板/静态文件
| `~default/#默认站点
| |+static/#静态资源文件，如css等
| |+templates/#Django模板目录
| |+templates_plus/#Django模板目录，用户将自己重写过的目标放到该目录
| `-……
|~src/#django的app目录
| |+account/#account相关app。具体站点通常会对用户中心进行定制，所以该app在实际应用中很可能需要针对实际情况进行修改。
| |+djangohelper/#一些django的辅助函数等，
| |+lbforum/#lbforum的主app，论坛功能都在改app中
| |+lbregistration/#registration app的lbforum扩展，主要去掉邮件地址认证功能
| |+onlineuser/#显示在线用户的app（可复用的django app，可脱离lbforum单独使用）
| `+simpleavatar/#头像功能的app（可复用的django app，可脱离lbforum单独使用，依赖djangohelper）
|+tools/#工程用到的辅助工具，目前只有一个virtualenv的脚本
django的url采用正则表达式进行配置，虽然强大却也广为诟病。反对者们认为django的url配置过于繁琐，且不支持默认的路由功能。
我倒觉得还好，只是如果觉得不爽，为什么不自己小小的hack一下，反正也就几行代码的事。
在这个背景下，我整了这个url_helper，利用url_helper可以简化配置和实现url的默认路由。所谓的url_helper其实就只有url_helper.py一个文件，使用的时候只想要import就可以。
url_helper的具体用法请参考具体的例子：
下面对使用方法做个简单的说明。
from url_helper import execute, url_
import views
urlpatterns += patterns('',
url(r'^(?P.*)', execute, {'views': views}),
)
在urls.py里增加如下配置，其中views为需要进行路由的views模块。url的规则为 /action/param1/param2/…/ 。
例如：
#/edit/4/
def edit(request, n="id"):
html = """ edit object: %s""" % n
return HttpResponse(html)
在没有指定action的时候默认使用的action为index。
仿照ROR的做法，参数用”:”标识。
例如：
url_(r’/space/:username/:tag/’, views.url_), 对应的django url配置为url(r’^space/(?P<username>[^/]+)/(?P<tag>[^/]+)/$’, views.url_),
#url_(r’/space/:username/:tag/’, views.url_),
#/space/vicalloy/just/
def url_(request, username, tag):
html = """ username: %s
tag: %s""" % (username, tag)
return HttpResponse(html)
就如前面说的，代码非常少。不过实际应用的话，应当还需要做一些扩展。
#!/usr/bin/env python
# -*- coding: UTF-8 -*-
from django import http
from django.conf.urls.defaults import url
import re
def execute(request, urls, views):
"""
urls [methodName/]param1/param2/.../
methodName default index
"""
def get_method(views, methodName):
try:
return getattr(views, methodName)
except Exception, e:
return None
method = None
params = [e for e in urls.split("/") if e]
params.reverse()
if params:
method = get_method(views, params.pop())
if not method:
method = get_method(views, 'index')
if not method:
raise http.Http404('The requested admin page does not exist.')
return method(request, *params)
def url_(*args,**dic):
regex = args[0]
if regex[0] == "/":
regex = regex[1:]
regex = '^' + regex
regex = regex + '$'
regex = re.sub(":[^/]+",
lambda matchobj: "(?P<%s>[^/]+)" % matchobj.group(0)[1:],
regex)
return url(regex, *args[1:], **dic)
今天部署了一个dpress的演示站点。
http://vik.haoluobo.com/dpress/
http://vik.haoluobo.com/dpress/admin 用户名：vicalloy 密码：vicalloy
感觉django的部署还是太麻烦…
用Django做Blog实在是太过简单，所以在网上可以轻易的找到大量用django实现的Blog，DPress就是其中一个。
本想用这个项目做Django最佳实践的教程，不过发现自己实在是不擅长这个。此外该项目花费的时间比预期的要多出不少，以至到后期挺没耐心，功能方面也因此大幅缩水。
目前DPress的基础功能已经完成，文档方面我会在晚些时候补上。
有兴趣的朋友可以将代码下回来看看。如果要使用Django自己服务器启动起来非常容易。
DPress本着以最少的代价完成最多工作的原则，能不造轮子的地方就不造轮子。
对Blog应用来说，一般都会有较高的个性化要求。换肤基本上成了必备功能。很遗憾，这方面是django的软肋。换肤需要创建新的模板，并需要修改配置文件，指定使用新模板。好的方面是，DPress的模板在我优化过后，还是比较简单，改起来还算方便的。
虽然在开始DPress之前就计划的很好，本以为很容易就可以搞定，但事与愿违开发过程中遇中还是遇到了一些麻烦。
Pinax中的Blog组件使用threadedcomments来增加评论支持。在评论内容填写不完整时，会转到它自定义的页面。我认为这是一个挺不友好的设置，尝试修正无果。切换到django.contrib.comments后问题则更糟，不但评论出错会跳到自定义页面，即使评论成功了不会转到评论页面，而是给出一个评论成功的提示。最后没办法，还是自己将添加评论的代码给写了一遍。
此外在模板方面也折腾掉了大量的时间。模板的本身也是程序中重要的一环，但不少的可重用app都没有带任何模板，而且也缺乏模板方面的范例。在我看来，这也是django的第三方app普遍不太好用的重要原因之一。
下面上张图吧，模板的样式，是偷的朋友BLOG的（他也是偷别人的）。
以前也翻译过一些东西，不过都是非常短的文字。今天在网上看到一篇关于unladen swallow（Google的python实现）的文章，于是尝试对其进行翻译。
翻译东西确实不是一件容易的事。外文文章要读懂很容易，你只想要关注其中的重点即可，对于一些不重要的地方即使你没读懂也没关系。在翻译的时候你很容易的就会陷入了原作者的语言习惯，但外文和中文的语言习惯还是有很大的差别。其中语言习惯的差别不仅仅表现在句式结构上，还会贯穿在整片文字的语言组织上。所以如果你是按句翻译，那不管你如何组织语言，依旧会读起来很拗口。
除技术因素外，翻译还是一个很考验耐心的活。一篇可以在几分钟内读完的文章翻译起来得花几个小时。
虽然翻译得比较糟糕（自己都不想再读一遍），不过总算翻译完了，如果哪天有空就再休整一下，至少不要读得这么恶心。
昨天收到网友的邮件说我做的农历插件无法使用。但我自己测试却没有发现啥问题。于是在自己的虚拟机里测试了下，还真无法工作了。
检查代码发现里面有runCommand(‘cal’)，这样的代码。去查了下，发现cal是linux查看日历的命令。估计是新版本的yahoo widgets去掉了相关命令的支持。重新下载了个yahoo官方的日历组件，将runCommand(‘cal’)用新版yahoo插件中相关代码替换后我的widget终于又可以正常工作了。
我的这个农历组件已经发布两年多了（看截图:-），直到现在才有人给我反馈（不过，我也不知道从啥时候开始出问题），看来这东西还真没几个人用。
虽然django的admin漂亮的实现了CRUD，不过在有时候admin并不是这么好用。然后开始进行手写CRUD，接着发现自己又陷入了重复操作中。相比而言Ruby自动生成的添加删除功能就好不少，你生成的基础框架是可以扩展的。
为了减少手动书写CRUD的工作量，我写了一个扩展的startapp command。使用这个命令会自动生成 list/new/edit 的操作和html文件（这样修改起来就方便多了）。
如需要在其他工程使用该命令，只需要将项目中的django_extensions文件夹复制到其他工程的app目录，并在settings.py里把django_extensions添加到app列表里。该扩展命令为create_app，使用方法和django官方的startapp一致（如：manage.py create_app blog）。
为了方便演示，该扩展命令包含了一个演示工程（hidjango）。下面的步骤是windows平台（因为用了几个bat）。
/django_extensions/conf/app_template/
|~templates/
| `~{{ app_name }}/
| |-base.html
| |-edit.html
| |-list.html
| `-new.html
|~templatetags/
| `-__init__.py
|-__init__.py
|-admin.py
|-forms.py
|-models.py
|-tests.py
|-urls.py
`-views.py