比较过rails和django

从来就没觉得这样的比较很恰当，为什么人们总是把这两样完全不同的东西进行比较。如果说乍看起来很像，那也应该是pylons而不是django，那么稍稍来了解一下pylons吧

Pylons的出现使得python世界之中的另外一个重要的framework TurboGears十分尴尬，Pylons和TurboGears几乎有着完全一致的设计理念，在我的理解中，Pylons实现得更加出色。个人观点：TurboGears可以不用搞了，注意：是个人观点。


Pylons的确是抄袭了很多框架的GoodIdea，在其中我们可以看到很多优秀的设计思想。

TG可能是最初吵着不要重复发明轮子的，于是写了一个脚本把一些它人为不错的东西捆绑了一起。这里面包括CherryPy和SQLAlchemy。Pylons做的更绝，不但绑了，而且绑了很多，比如你可以选择SQLAlchemy也可以选择SQLObject

再来说说和Rails很像的地方，关于Session的处理，它是可以放在各种地方，数据库，文件系统，Rails也是。但是Django不是，全部丢进数据库了，或许将来会有不同的打算。另外URL Dispatch方面Pylons使用的是Routes，它的主页上已经明确表明自己是Rails风格的Dispatcher。最后看看目录结构，和Rails一样让人莫不着头脑，当然仅对新手而言。

事实上，很长一段时间以来，我都没有去仔细了解Pylons。原因是我一直都没有正确的认识到Paste是什么。我自做聪明的认为Paste是一个脚本，但最后我才发现，Paste本身就是一个framework，非常low level的framework。这更加让人拍案叫绝。当TG开始整合各种库的时候，好比自己新写了一个类。但是Pylons从一开始就是继承了一个类，整个工作就在别人的基础上实现了，连自己这个轮子都不再需要被重新发明了。

像基本的输入/输出这样的功能，Pylons就是靠继承Paste得来的，顺便Pylons还得到了一个调式服务器和生成项目需要的脚本，这在几乎所有的框架中都有，Pylons当然也不能少。

接着Pylons需要一些模块来完成它需要的功能：为了实现像rails一样的URL Dispatch，Pylons吸收了Routes。为了实现Session和Cache，Pylons使用了Beaker。当需要模版引擎的时候，Pylons为我们提供了一堆候选者，Mako，Myght，Kid⋯⋯数据库还有SQLAlchemy和SQLObject两个现成的可以使用。Ajax也还有很多选择。

现在，Pylons的结构就大概的呈现在我们眼前了

django的orm看起来相当的简单，但是要想用好，就得花上一些时间去仔细阅读reference了

只有应用中才会发现不足

往往做一些简单的应用，select都是等号。但是我们遇到了一个稍微别致的应用，查字典

Dictionary.objects.filter(word = w)

这样明显不行，如果我查询"china"一定找不到，因为是精确的match，所以你要输入"China"才可以找到中国
在这样紧急的情况，我们需要的是立刻查阅reference，原来上面的那一句等同于下面的

Dictionary.objects.filter(word__exact = w)

想要让查询忽略大小写，下面的写法就可以实现

Dictionary.objects.filter(word__iexact = w)

新的想法，当我输入前几个字的时候，可以查找出所有可能的单词

Dictionary.objects.filter(word__istartswith = w)

于是我们可以更加多样的控制SQL语句之中WHERE后面的条件，而不仅仅是等于
* exact
* iexact
* contains
* icontains
* gt
* gte
* lt
* lte
* in
* startswith
* istartswith
* endswith
* iendswith
* range
* year
* month
* day
* isnull
* search
* regex
* iregex
Django ORM为我们提供了这样的工具

无数人都把 rails 和 django 当作差不多的东西，有些人甚至用到了 clone 一词

作为一个用户，我喜欢python，于是从而选择django，看起来顺理成章。不过rails真的和django一样吗？我只能努力的去寻找一点不同之处。真的，我很期待可以从中看到不同的想法

很多人都从 ruby on rails 网站上的秀 textmate 的那些视频开始首次接触 rails ，如果不出意外，很多人也是从这里第一次认识ruby。

即使很多人不愿意承认，他们实际上还是被scafford弄的一头雾水。那段视频总是给人以似懂非懂的感觉，有的时候让人觉得是在变魔术。

django的orm是从一个class推导出一个 database scheme ，类似这样的操作在rails 中不存在，人们必须直面SQL语句，或者使用GUI工具。django的方法明显受到了python的orm工具sqlobject的影响，对于初学者略微友好

从某种角度说，rails在某一方面更加体现了DRY，django略逊一筹。当一个数据模型建立以后，scafford给人的感觉是自我感知了这个模型，并自动生成了操作该模型的CURD(Create Update Read Delete)的Views，而使用django的人似乎不容易习惯这样的方式，往往选择手动创建 view 来操作 model

其实django也有从model直接生成view的工具，其实是表单工具。这样实现CU的问题就不是很大。但是和scafford的一站式服务相比，还是显得有些麻烦。不过newform的出现，已经给django增加了不少生产力，或许django已经决定走这种灵活路线的DRY了吧！

花了好长时间才领悟scafford哲学，这就是我不努力学习rails的结果⋯⋯自嘲中！

The first public release of Django was tagged in Subversion at 7/15/2005.
7/15/2005是django的第一个release
到现在已经两岁了

它的对手rails，生日是7/30，三岁
虽然生日很接近，但是由于星座不同，所以表现出来的性格也大为不同。一般来说，狮子座比较爱出风头……

巨蟹座我就不好评价了
PS: 我是巨蟹座

单用户系统理论上是不需要username的，非常人性化的思考，既然id只有一个，那么为什么还需要输入呢！

django的auth模块似乎不是为此准备的。它是一个很规范的用户管理系统，有用户名，有密码，有last_login⋯⋯其实我很不喜欢，所谓杀鸡用牛刀～～～

写一个，simple_auth，却引出了session问题

WEB本无状态，后来有了动态技术，才有了session。喜欢PHP的人很少用session，能用cookie就用，不能用就另外想办法。但是django希望彻底解决问题，在你的cookie中放一个GUID，其余的session信息就放到数据库中了

但是对于一个简单的系统来说，使用数据库又是一个‘牛刀’的问题了，虽然sqlite和使用文件已经没有什么区别了，但是我依然想坚持风格，干脆把django的session系统也黑了，彻底脱离数据库依赖

我们许要一套代替auth的模块，于是我建立了simple_auth模块，user.py目录中的两个类可以让密码不存储在数据库中，而是直接存储在文本文件中。

class SingleUserManager:
    
    def authenticate(self, username=None, password=None):
        '''authenticate'''
        user = SingleUser()
        if user.check_password(password):
            return user
        else:
            return None


    def get_user(self, user_id = None):
        '''get_user'''
        return SingleUser()


class SingleUser:


    def __init__(self):
        self.id = None
        self.backend = "%s.%s" % (SingleUserManager.__module__, 
                                                    'SingleUserManager')
        self.password_changed = False
        
    def check_password(self,raw_password):
        '''check password'''
        
        import md5
        f = open('passwd','r')
        self.password = f.read()
        f.close()
        
        if self.password == md5.new(raw_password).hexdigest():
            self.id = 0
            self.username = 'no need'
            return True
        
        return False
    
    def is_anonymous(self):
        return False
    
    def save(self):
        pass

虽然没有完美的模拟User对象，但是这里足够用了

按照django本来推荐的使用方法，验证一个用户是

user = authenticate(username=username, password=password)
if user is not None:
    login(request, user)

现在替换成

users = SingleUserManager()
if users.authenticate(None,request.POST['password']):
    auth.login(request, users.get_user())

接下来要做的是精简MiddleWare,让settings.py的INSTALLED_APPS参数只保留一个session，这样可以在manage.py syncdb建立数据库的时候，只许要建立session的数据表。因为auth的依赖的数据库表已经被我们干掉了，所以现在只有session还在使用数据库。
另外，MIDDLEWARE_CLASSES也修改成下面的样子

MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    #'django.middleware.doc.XViewMiddleware',
)

这样，网站基本上还能跑起来，auth模块是不能访问了

现在，在只有session的表使用数据库了。接下来我们会写一个session替代的MiddleWare，彻底摒弃数据库⋯⋯