Chandler摆脱了XML的困扰

　　这已经成为了最终的共识。Chandler的XML打包模式正被诟病，并且将很快完全消失，整个被简单的Python APIs所代替。读者可能会由此想到我的那篇文章：Python Is Not Java rant，那篇文章中，我认为用XML做核心应用功能是不明智的。在the PyCon Chandler sprint,人们发现，Chandler的XML计划定义语言给开发者造成了巨大的困扰，所以，我用基于描述符的Python API来替代它。这个替代完成后，只有一些数据项目的初始数据（例如Chandler的用户界面组成）还在用XML完成。所以，过了几个星期，对于数据项的初始化，我也执行了试验性的API，这种做法很快变得非常普遍，有些人甚至指出其优点是可以重复使用。
　　一度，还存在一个为了用户界面定义（UI definition）创造一个新的XML格式的建议。但我持相反意见：采用一个简单模版群（template class）和一个类方法（classmethod）代替它，已能让大家都满意。
很多人都错误理解或者错误表达了我之前在XML上的观点；Chandler的案例有助于澄清这个错误。Chandler仍然将XML用于WebDAV、.xrc文件、分享以及大量的其他使用案例，只要有一点理由在那里这样做。然而，XML打包模式在过去是种纯粹的练习，缺乏实用性：用冗长的复杂语言去做那些本来用Python代码能写得简洁有效的事情。后来，它发展到为Chandler的一个“数据驱动（data-driven）”系统的版本服务，而且它被认为最终能够支持GUI编辑器（editors）这种工具  。
     当然，真正的缺陷并不仅仅因为XML语句，而是在需求之前过渡的工程化。如果你现在还没有开发任何功能，那么最好是不要基于个人猜想武断的做出开发功能的其它设计决定。一些很小的事情，比如选择在XML格式上安插数据，都会导致一系列额外的代价，例如：
　　• 设计XML格式!
　　• 安装/执行解析器
　　• 文档化格式
　　• 在格式里开发大量东西
　　• 不断修改和更新解析器来处理越来越多的以前没有想到的复杂用例
　　• 和使用Python的结果相比，生产力已经降低
　　• 一旦你确认它是一个坏主意就转换所有的数据，否则就要为第三方开发者攻克难关付出随之而来的市场和教育的成本，或者是付出从国外聘请符合条件开发者的成本。
　　用来增加你并不需要的功能的代价实在太高了。幸好，OSAF认为更重要的是作正确的事情，而不是一直把钱扔在老鼠洞里来证明钱已经花掉了。我曾经在这样的企业工作过，他们投下数千万美元要试着用一个昂贵的“企业”垃圾软件替换一个小巧、设计良好的Python应用软件。这些钱我本可以用于以下计划！——给每个人加薪，雇用更多的人。或者可能把我的团队扩展成一个能够把软件卖给其他公司的公司。见鬼去吧，用这些钱，我们本来可以来给公司员工买终身免费的饮料，为投资者带来更多价值。
　　我得说点别的。关键是：推迟了好的功能开发投资，陷入了坏的错误投资。难道不是吗？

（原文链接网址：http://dirtsimple.org/2005/08/chandler-begins-recovery-from-xml.html，Phillip J. Eby先生的英文blog网址：http://dirtsimple.org/）

 

译者注：Phillip J. Eby的blog在国外软件开发领域影响很大，广为流传的两篇文章是：“Python Is Not Java”与“Java is not Python, either...”，CSDN会陆续为大家奉上。他还是一位多面手，除了在Python上的深厚造诣外，在心理学研究上也颇有建树，著作有《You, Version 2.0》。