标签归档：django

DPress-Django开发的Blog

用Django做Blog实在是太过简单，所以在网上可以轻易的找到大量用django实现的Blog，DPress就是其中一个。

本想用这个项目做Django最佳实践的教程，不过发现自己实在是不擅长这个。此外该项目花费的时间比预期的要多出不少，以至到后期挺没耐心，功能方面也因此大幅缩水。

目前DPress的基础功能已经完成，文档方面我会在晚些时候补上。

有兴趣的朋友可以将代码下回来看看。如果要使用Django自己服务器启动起来非常容易。

  1. 使用SVN把代码下回来 http://dpress.googlecode.com/svn/trunk/ 。
  2. 运行 \trunk\scripts\init.bat 完成一些必要的初始化（复制静态文件到相关目录）。
  3. 运行 \trunk\site\dpress\scripts\syncdb.bat 初始化数据库。
  4. 运行 \trunk\site\dpress\scripts\runserver.bat 启动服务。
  5. 访问 http://127.0.0.1:8000/admin/ 在管理后台添加日志。

DPress本着以最少的代价完成最多工作的原则，能不造轮子的地方就不造轮子。

  • Blog的编辑功能完全交给admin处理。
  • 使用filebrowser对admin扩展，实现对文件的管理。
  • 使用django-tinymce，实现html的可视化编辑。
  • 文章的Tag功能使用django-tagging实现。
  • comments功能使用django.contrib.comments。
  • Blog本身也大量“借鉴”了pinax的blog组件。
  • Blog支持使用书写格式有Markdown、Textile、普通文本，html（支持可视化编辑）、reStructuredText（当然，你需要安装有相关的库）。

对Blog应用来说，一般都会有较高的个性化要求。换肤基本上成了必备功能。很遗憾，这方面是django的软肋。换肤需要创建新的模板，并需要修改配置文件，指定使用新模板。好的方面是，DPress的模板在我优化过后，还是比较简单，改起来还算方便的。

虽然在开始DPress之前就计划的很好，本以为很容易就可以搞定，但事与愿违开发过程中遇中还是遇到了一些麻烦。

Pinax中的Blog组件使用threadedcomments来增加评论支持。在评论内容填写不完整时，会转到它自定义的页面。我认为这是一个挺不友好的设置，尝试修正无果。切换到django.contrib.comments后问题则更糟，不但评论出错会跳到自定义页面，即使评论成功了不会转到评论页面，而是给出一个评论成功的提示。最后没办法，还是自己将添加评论的代码给写了一遍。

此外在模板方面也折腾掉了大量的时间。模板的本身也是程序中重要的一环，但不少的可重用app都没有带任何模板，而且也缺乏模板方面的范例。在我看来，这也是django的第三方app普遍不太好用的重要原因之一。

下面上张图吧，模板的样式，是偷的朋友BLOG的（他也是偷别人的）。

django-tagging的使用方法

django使用app机制来实现组件的重用，充分的利用已有的app可以极大的简化开发工作。目前django下的app虽然还不够丰富，却也还是有部分不错的。django-tagging就是一个不错的app。

现在tag的应用非常广泛，tag基本上成了各网站的必备项目之一，django-tagging就是一个提供tag功能的app。django-tagging提供的功能非常丰富，使用起来却十分简单。下面我就介绍一些常用的用法，让大家对该app有个基本的了解，更详细的介绍还是老老实实的去看django-tagging的使用说明吧:)。

tagging.fields.TagField

我们先定义一个数据库模型Widget，下面的范例都用Widget来进行说明

class Widget(models.Model):
   name = models.CharField(max_length=50)
   tags = TagField()

就如上面的代码，只要在数据库模型中增加tags字段就可以为该对象提供tag支持了。tags被映射为CharField，在为对象添加tag时为，英文逗号分割的字符串如：

Widget(name='hello', tags='test,hi,hello')

这样就为新建立的对象添加了test hi hello三个tag了。

获取某个tag下的所有对象的代码如下：

    #取出所有属于TAG hi的对象
    tag = get_object_or_404(Tag, name='hi')
    widgets = TaggedItem.objects.get_by_model(Widget, tag)

如要取出Widget用到的所有tag的代码为：

    tags = Widget.tags.all()

完成对老照片的调整，Django版本升级到1.0

今天完成了对老照片的调整，将Django的版本升级到了1.0。1.0版本的Django相比以前版本相比最大的变化就是那个newforms了。不过好在我在newforms出来不久就直接切换过去了，这次升级只需要在import的时候将newforms改成forms就可以。
admin也是0.96到1.0变化比较大的。不过老照片本来就不太依赖admin，所以我只修改了admin的url映射部分，保证admin后台可以正常打开。以后如果需要用到admin，再对admin部分进行调整。
由于我需要对用户上传的图片进行编辑，因此没有使用Django默认的上传处理。文件上传的变动给我带来了不少麻烦。以前从request.files里取出的文件是个map，但在新版本中变成了一个对象。这个对象虽然提供了files的相关接口，但却又不全，导致PIL无法正常处理。为此我增加了一个临时文件。先将用户上传的文件保存到临时文件再进行处理。在网上看到有用户遇到了和我同样的问题，不知Django在日后的版本中是否会修正。
至于目录的调整，我将那个碍眼的apps给去掉，把所有的文件放到oldphoto这个包下。
此外对项目的配置文件做了一些调整，将默认的数据库改为sqlite，保证程序可以在不做任何设置的情况下直接用manage.py runserver跑起来。
最后再将项目地址贴一下：
http://code.google.com/p/oldphoto/
将项目从SVN中取下后，依次运行scripts目录里的syncdb.bat、runserver.bat就可以跑起来了。当然，那些有些必备的环境还是需要的，python(>=2.4)+django(>=1.0)+PIL。

后记

本来休整工作还包括部分重构以及i18n等，不过在完成Django的升级后就开始没多少兴趣了。由于代码比较老，里面不少东西在现在看来都有更好的处理方式，如果全部都改工作量有点大，只是改部分打打补丁又没多少意思。或许那天重新写个自己看得顺眼点的新项目。