为四川人民祈祷! www.onefoundation.cn
Tag: Jampad
我终于决定放弃将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   
kernel1983
花掉了两个晚上的时间,把pikipiki这样的cgi程序port称为了一个wsgiapp,事情还没远有结束,不过我隐约看到了一些成果

其实这样的port工作内容很简单,新建一个StringIO就叫他buf吧,被我当成内存文件用了。把所有的print替换成print >>buf,一切乱七八糟的内容就都被我截获了,这些内容我当成WsgiClient的输出就可以了

另外一件重要的工作,就是把所有从cgi对象中请求信息的行为,替换成从environ字典的某个对象请求,为此我还特地写了一个函数

完成了这两件大事,我们就可以在把程序嫁接到WsgiServer上了。我选用的是CherryPy的实现,当成我的测试开发服务器

OK!
Tag一下
稍稍整理一下代码,SVN上见……
comments: 0 | tags: Jampad   
kernel1983
最近正在做的一项工作,就是重新写一遍Jampad。

在刚刚过去的那个时代,Jampad这个简单够用的wiki是一个基于PHP的程序。本来以为程序很小,甚至不需要封装。事实证明在PHP这样的Perl式语法(带美元符号的语法)中,结构化编程带来的副作用是巨大的,你永远都不会期待这样一个无比巨大的case

现在的计划是用Python重新让我的Jampad跑起来,并保留原来的数据。重新制造轮子已经是我们笑话刚刚入门的Geek们的时候经常使用的话题,所以现在的代码绝对不能从零开始,于是我追随着时间轴找到了一个使用Python写作的,古老的CGI程序——pikipiki,并加以改造

如果你看过我前几天写的文章,或许你会明白我的意图了——WSGI,没错,把一个CGI程序Port到一个基于WSGI的标准,这样我们有机会摆脱掉任何框架~~~Django,TurboGears,Pylons……邪恶的思想萌芽,让人热血沸腾

这样的好处就是,享受Python世界中对于WSGI的一切优点,你的程序可以被CGI或者FCGI等任意的环境支持。我好像一直在重复这个观点

OK!
I‘ve got a target.
comments: 0 | tags: Jampad   
kernel1983