Friday, 24 February 2006

Ingredients to the Pylons Python Web Framework

Pylons的大鸟Ben Bangert,刚刚发了一篇“Ingredients to the Pylons Python Web Framework”,对于理解Pylons的整体架构很有帮助。

Apple, Orange, GUI, PHP, Framework

在Apple上逛了一下,一不小心又碰到一个框架。Green Orange,一个PHP框架,提供GUI的开发模式,在浏览器上开发应用。Sound's good。有空的时候,倒要看看这能进苹果园的绿橙子,到底是啥样。

这Web Application Framework的树林,看来是越来越大了。

Thursday, 23 February 2006

学用Myghty作Pylons的模板

Pylons中的模板,取自于MyghtyMyghty本身不仅仅是模板,而是一个完整的框架。如果完整地学习Myghty,那有些东西在Pylons中实际是没有用的,或者是不能用的。Myghty这块馅饼,怎么开吃就是个问题。要是有个Sample就好了。

翻了翻Myghty Egg里的内容,Myghty 1.0带了三个paster模板。其实也就是三个例子。通过paster create命令,创建基于这些模板的sample project。我是从simple template开始的,把Myghty project下面的myt和myc文件,拿到Pylons project里面来。这样就能够直接在Pylons下面,就着Myghty的例子来学Myghty了。

我现在的理解,View这一块,Pylons直接用Myghty,模板之间的关系可以照搬;在Pylons中需要注意的是,如何在controller和template之间完成数据传递。

Sunday, 19 February 2006

Pylons的动静有点大

刚才同步了一下Pylons,版本到了0.8dev_r662。一同升级的有Routes(1.2),还多了一个nose(0.86)。这个nose是用来作单元测试的,细节未知。

从r618到r662,上周末写的测试code已经不能跑了,从一堆error message里看,应该是和Routes有关。对于只有dev的东西来讲,这当然是正常的。一切都在趋向更好、更稳定。

一个我比较喜欢的变化是,有了models子目录。这下controller、model和template终于各自有明确的位置了。

Ben在邮件列表中提到,0.8会很快release。这是个好消息。

Friday, 17 February 2006

pyDev可以实用了

大约在一个月以前,我曾经试用过PyDev,版本大概是0.9.1(具体的忘记了)。作为IDE来讲,Debug的功能是最重要的。那个版本在进入Debug模式以后,其步进的速度,实在令人不堪。“删”立决。

昨日说到JpyDbg,又想起了这档事。查了查,Eclipse已经到了3.1.2,PyDev的最新版是1.0.1,已过了1.0版本。当即重审,性能和稳定性已有了非常明显的提高。Debug的速度不能说是飞快,基本上和其它Python IDE类似;自动完成,使用起来也还行。软件1.0版本这个里程碑,过不过,真的是不一样。PyDev现在的状况,已经可以实用了。

安装PyDev的一个小问题,文档中提到的Eclipse update链接是http://pydev.sf.net/updates/。在Eclipse中设置此链接,似乎抓不到1.0.1版本,使用真正的链接http://pydev.sourceforge.net/updates/没有问题。

Thursday, 16 February 2006

JpyDbg - 把NetBeans变成Python IDE

最近使用NetBeans 5.0,其运行速度非常令人满意。顺便google了一下,有没有For Python的插件,还真有 - JpyDbg。其支持页面在这里

试用了一下,尽管目前的整合程度还不高,但基本的高亮显示、调试跟踪、以及中间变量显示等IDE的基本要素都有了,Debug是通过前后台的套接字通讯来实现的,其过程其实和调试Java程序一样自然,速度也很快。

JpyDbg还可以作为jEdit的plug-in。如果觉得NetBeans太大,也可以使用JEdit + JpyDbg来作为Python的IDE。

Sunday, 12 February 2006

Paste Serve

Pylons的管理底层用的是Python Paste,以此来实现应用的产生、管理以及运行。其中最重要的、用得最多的就是Paste Serve。在Paste.Scipt文档中,有关如何设置运行参数、配置文件,乃至如何在Unix系统下是书写Service Script文件,都有详细的描述。

似乎看来Python Paste is ready for multiapp。在开发阶段,无所谓;在运行期,准备好Python Egg,轻松实现multiapp。Paste Serve命令本身,实际只能Serve一个App,启动一个Server。配合daemon选项,通过fork的方法,来实现multiapp的。

在Windows下面,deamon选项是不能工作的。因为Windows中没有fork。通过其它手段,并不影响multiapp的使用。

xlp223提到在SVN上新出现multiapp分支,还不清楚其和Paste Serve所提供的multiapp有什么diff。个人猜测可能和多应用间的协同有关,使得pylons的应用更适合Paste Multiapp的要求,而不是提供Serve Multiapp。

pylons的粗浅印象

进行了pylons的一个简单而完整的试验。对pylons也有了一些粗略的认识。前些日子,也用TurboGears做了类似的试验,感觉上更喜欢pylons多一些。昨晚,和xlp223交流了一些彼此的看法,获益良多。

从架构上来讲,TurboGears是直接建立在MochiKitKidCherryPySQLObject的基础之上。TurboGears和基础构件之间耦合地比较紧密。pylons则包括了MyghtyRoutesPaste等更多的构件。直觉上,却不因此而显得凌乱,反而更直观、更弹性。

pylons的文件结构清晰,应用的后续发展会比较简单、直接,感觉已经成熟。URL Mapping这一块,由Routes来完成,也比较简单、方便。Myghty,已经有很长的发展历史,是成熟的模板系统。SQLObject大家都在用。

pylons和构件之间不是强耦合,有中间的粘结层,构件可替换,使得它很有弹性。总的感觉,pylons是建立在相对成熟的构件基础上的,即使将来某些组件会有些变化,但整体框架基本成熟,接近稳定。相对的,TurboGears的变数比较大,成熟度不高,以后发展的样子不好说,目前需慎行。

另外一点,pylons的文档相对版本的发展,有些滞后,可能人员数目不够。新的东西,不能及时反映到Doc中,多少会影响整体的发展。TurboGears则相反,文档居然超前,说了再做的风格,个人不以为然。

Saturday, 11 February 2006

Google - 简单还是复杂

有人说,感谢上帝,给我们Google。想问什么,只要Google一下就行了。Google,是名词还是动词?

回到Python WAF的问题上,Google给我们的答案不是太少了,而是太多了。一个要求推荐WAF的问帖,可以有近百个跟帖。一个比较TurboGears和Django人员活跃程度的blog,也会引来20个Comments。更有这样全面的统计

Google,到底把问题搞简单了,还是搞复杂了?

You can ask Google.

Friday, 10 February 2006

Python WAF的零碎

在搜索其它东西的时候,一不小心又看到一个 Python WAF- Pylons,建立在MyghtyRoutes Paste的基础上的呵呵,也就是在Paste上又加点调料。Paste我喜欢,这Pylons一定要尝一尝。不幸的是,从它的SVN上checkout总是出错,不能马上试。

差点忘了,网上还有人画了几个WAF和基础构件的关系图,在这里。看看满有趣的。


后记:数小时后,SVN终于恢复正常,安装成功Pylons。Pylons集成(依赖)的egg可真多,幸好有easy_install帮忙。不过在coLinux中,又遇到和Karrigell类似的速度问题,CPU不“兴奋”,莫名其妙的慢,不在嵌入式系统里却是没有问题。相对应的,TurboGears倒是跑得挺欢。

Thursday, 9 February 2006

开始Python Web应用框架

不想继续把时间停留在不停地安装、测试上了。就是TurboGears,外带Karrigell了。

通过easy_install是非常容易安装TurboGears的,第一个能显示一条记录的Application做出来了。目前,对URL Path映射还不太习惯。Kid模板上的语法,是XML规范的,<br/>不能写成<br>,浪费了一点时间。

Karrigell,还不错,比较对我这种Programmer的胃口。目前唯一的问题是,其在coLinux中的运行速度出人意料的慢。另外,easy_install无法安装Karrigell(2.2.1),找不到setup.py。

另外,coLinux上pySqlite2,需要自己先编译、安装SQLite3,才能easy_install pysqlite。Debian Stable版本的sqlite3不提供sqlite3.h头文件和动态库链接。

PHP CMS的试用结果

PHP CMS非常的流行,从大到小,可以选择的系统众多。经过前一段时间的试用和筛选。最后,我留下了4个,Lite 2个,Medium 1个,Huge 1个。

筛选的过程,是在Windows和Linux中进行。个人设定的前提条件,是要提供对PostgreSQL或SQLite的支持。不幸的是,几乎所有的CMS都是基于MySQL的,少有支持PostgreSQL、SQLite的。这大概和PHP以前集成MySQL,PostgreSQL没有Windows版本的这段历史有关吧。

Lite PHP CMS:

  • limbo,小巧、方便,甚至可以不用数据库支持,Joomla的模板大都可以套用。
  • toendaCMS,有德式的严谨,支持PostgreSQL和SQLite,小型应用够了。
Medium PHP CMS:
  • Joomla,最火爆的CMS,模板众多,人气很旺,发展空间大。预计1.1版开始提供数据库抽象层,支持PostgreSQL。
Huge PHP CMS:
  • Typo3,典型的德式产品,真正以内容为中心的管理系统,精细的控制,扩展库规模巨大,很难相信会有这样大型的Open Source软件。有数据抽象层扩展,间接支持PostgreSQL。

测试所用是一个嵌入式的Linux - coLinux,核心是Debian Linux,其表现非常稳健。128M + 1G,就可以在Windows里打造一个优秀的Server。在Windows下,同样也建立了AMP的运行环境,作了相应的测试。作为Server来讲,Linux对Windows的优势,非常明显。两个平台下,运行时的各项参数,根本不是一个量级,最直接的表现,是系统噪音和反应速度上。尽管如此,拿Windows XP和嵌入式Linux,来代表双方在服务器领域的表现,其实是有失公允的,因为Linux不涉及到GUI部分。如果把coLinux用作个人开发和测试的服务器平台,是非常理想的。coLinux,或许才是我这次试验的最大收获。

在coLinux上测试的另一结果是,PostgreSQL(8.1)的运行表现,的确要好于MySQL(5.0)。MySQL的问题是,对系统环境要求高,外部连接时速度慢。(外部连接,指的是通过TCP/IP,跨IP的连接。)

PHP CMS的选择,终于可以告一个段落。Limbo和toenda,反正是拿来就可以用,不需花费什么时间。Joolma,也是容易上手的,个人看好其以后的发展。Typo3,这个大炮级的东西会继续保留,目前欠着两篇短文,一篇是如何用coLinux建立Typo3的开发环境,另一篇打算讲一下Typo3对虚拟多站的支持,这也是要有Linux支持的,Windows下做不了。Typo3的应用,非一日之功,很怀疑自己能否持续深入下去。

因为PHP不是我主要发展的方向,以后一段时间里也就不会再涉及这方面的内容。也不知道何时再重拾CMS。

回过头,继续漫漫的Python之旅。