为四川人民祈祷! www.onefoundation.cn
logo of kjam.org
Archive: 2007-5

替换掉django的auth

单用户系统理论上是不需要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,彻底摒弃数据库⋯⋯
comments: 12 | tags: django   
by kernel1983

透透气

Dreamhost果然牛
什么招呼都没打,就给服务器换了IP。
开始还以为服务器问题,昨天晚上才发现IP地址已经无效了。不知道这里有多久没能访问……

疯狂的写了一天的django,在上次直接基于WSGI的尝试失败以后。虽然很想在某些应用中尝试Pylons,但是整天关心framework而不是去面对实际问题,绝对是一种病态的思想

Django不愧为 Guido van Rossum 老大钦点的框架,开发效率的确很高

和Rails相比,最讨厌generator。开始学的时候,根本不知道这个脚本里面都做了哪些事情。当你想要给目录rename的时候,你也必须考虑这样做的后果,或许刚刚的工作要从头开始?

django也有manage.py startapp,但是我们可以完全不用它。startproject建立起来的目录结构也很清晰,实在是太棒了!

现在Jampad从PHP port2 Python(Django)的工作已经完成。

或许接下来两天,Jampad的新版本就要重新开张了……这个好用的个人wiki已经在我的site上面消失了好久,连我自己都急切的盼望它Reload的那一天。

接下来的目标是很实际的,我一直为不能在这个BLOG上贴图感到不爽。我不想简单的添加一个文件上传按钮,我需要一个基于WEB的文件管理器。没错,下一个目标!已经开始了


TIOBE上面的语言排名,Python已经干掉C#上升到第七了,在它前面的是Perl,是个大家伙。我认为Python超过Perl是指日可待但是又非常重要的一天,因为Perl是被很多计算机高手中使用的语言,毕竟老了……

看着后面穷追猛打的ruby,我很高兴的看到很多Java用户在选择了Ruby之后有机会看到Python的优点,并且最终加入到Python阵营中来。Ruby的发展给动态语言打了一个完美的广告,也充分起到了猎头公司的作用。问题是,只有一个Rails框架的Ruby世界,吸引眼球固然简单,应用中要经得起考验才行!多元化的世界,存在是不需要理由的。

好多天都不写BLOG了,充分显示了Pythoner只做事不说话的原则!不过,难得出来透透气
comments: 1  
by kernel1983

pikipikipiki goodbye

我终于决定放弃将Piki Port to WSGI这个想法了,虽然此时程序已经可以运行在WSGI Server环境,但是我即将大谈我的感想(感想排名不分先后)

1.框架不是一群无事可做的疯子写的

也许我们永远不会明白为什么这个世界有这么多框架(Python世界),也许我们明天就已经明白了。因为我们从头(WSGI)开始过,就这么简单!没有从头开始过的人,不会想到当自己解决完一个问题,依然需要面对接下来十个问题时候的痛苦,尤其是在赶时间的时候⋯⋯我想这样的理由同样适用于MFC或者Java之类一切有轮子的东西

2.直接在WSGI基础上开始工作并不是一件不可能的事情,但是没有人愿意做两次

但是为了真理,你至少得玩上一次⋯⋯这绝对可以帮助你理解你所使用的框架。如果你学JSP,你得会Servlet。玩Ruby,最好还是看一看Rails源码。

3.使用框架并不丢人

PHP是用C语言开发的WEB框架,C是用ASM写出来的万能框架

那么,同理,Python是用C写的基本万能的框架,Django/Pylons就是用Python写的WEB框架!对无聊的人补充一点:不比PHP慢,WEB的瓶颈不在CPU,大家都知道。

4.有这么多框架可以选择,太完美了

说这句话Rubyer肯定要嫉妒死,我们有Django,你们却只有Rails。但是,我们还有Pylons,还有TurboGear,还有⋯⋯不计其数。

如果现在要我做VeryCD或者douban,那么Pylons肯定是我的选择了,原因就和打CS之前要买枪一样简单,当然要选最先进和最适合自己的装备。这么说来TurboGears也在选择之列,不过Pylons更底层一点。

如果现在要我选择一种框架继续我的Jampad2,那么肯定是Django,快速开发是唯一的原因,个人网站不会追求那些缥缈的性能。


好了,写完了

还有一个要说的,放弃使用piki的原因,因为:

1.它的模版实现的思想太古老了,真的有代沟了
2.协议,pikipiki是GPL,Jampad更加倾向于BSD

正如我所说的,django或许是更好的选择。
comments: 289 | tags: Jampad   
by kernel1983

OO vs NS

面向对象技术很早就已经出现了,在过去的十多年中被人认识,熟知并追捧⋯⋯在那之后,如果某种语言不声称自己是面向对象的,必然遭到大众的遗忘

面向对象技术是重要的软件技术之一,但是说实话,也不是那么神圣。大多数的时候,我们几乎无需使用它

很多人认为写类就是面向对象了,在这里我必须指出,很多人写了无数个class以后依然没有使用过面向对象技术,其实他在使用的叫做命名空间(namespace)。没错,在C++等很多种语言中,都有这样的概念存在,C和PHP没有。许多人定义类实际上只是为了使用命名空间。

为什么,因为问题远没有复杂到需要OOP的程度。我们没有使用继承,没有抽象类,没有虚函数。我们不需要设计模式,我们要做的仅仅是做在一台电脑面前,默默的敲下代码,完成一件事情,一个程序只需要main()一个函数。

是的,最简单的情况正如上面所说的,当退出main()的时候,函数中的所有数据都被清除了。问题再复杂一点的时候,全局变量就是我们最简单的选择。但是事实远不像我们所想的那么简单,这也就是为什么世俗的眼光如此仇视全局变量的原因。

很明显,在程序简单的情况下,这样完全没有问题。一旦你的程序需要为别的程序服务,所有人必须保证自己的全局变量不会被别人使用,要不你可以在变量前面加上复杂的前缀,要不我们开始在迫于世俗的压力下用类来封装自己的代码。

我相信,迫于这样的压力做这样的事情的朋友都不会承认自己在使用OO技术。还是同样的原因,问题根本没有那么复杂。他们一定相信函数就可以解决这类问题,只是迫于世俗的压力去把代码封装成类。他们使用的技术实际上就是命名空间

我们很容易发现一个观点,似乎全局对象比较容易被别人接受,然而全局变量却被人所不齿。崇尚设计模式的人,一定空想着一个低耦合性的世界。然而,理想世界很遥远,或许真的有这样的完美世界,现在,我们依然要忍受着现实的缺憾⋯⋯哈哈,扯远了

我想说的是,就算你是一个OOP的坚决反对者,或者标榜自己对lambda是如何,那也不妨碍自己定义几个class

就像zen of python中所说的,命名空间是个好东西,让我们用吧
comments: 1964  
by kernel1983
1