关于jQuery xml版英文文档的一些事

其实去年年底，jQuery 1.3尚未发布的时候就已经盘算着将中文文档以xml的形式发布了。这样有个好处，就是页面结构可以用xsl随便换。各位同学想做不同的发行版可以随便换着玩~实际上我现在愈发觉得css的局限性了，很多时候所谓的css为了后期维护方便，可以任意修改布局而无需动页面结构之类的话语已经觉得难以置信了。我就不信有多少同学遇到过改版的时候只改css而不改html的。当然也有可能是我的局限性而非css的局限性。

所谓的圣杯布局和双飞翼布局确实在很大程度上能解决布局(Layout)上的问题，但别忘了，开发工作可不只是布局，还有排版(Typography)，数据结构和页面表现结构交织在一起的时候，想崩溃都觉得老板会从地域里拖你起来。

xml+xslt这种手段其实我几年前就看到过，当时也曾为之心动，无奈当时技术水平有限无法体会其中精妙。然借此jQuery 1.3文档大改之际便又萌发了尝试的冲动。

xml+xslt好吗？很好！居然ie 5就开始支持了，ie 6支持的程度也很不错，基本上没有遇到什么兼容性问题，比起万恶的ie6对css的支持度好多了。目前我除了发现document()函数在ie中表现的跟其他浏览器不一致之外，以及Firefox居然不支持disable-output-escaping=”yes”，并且争论长达7年多尚未有解决的迹象。除此之外似乎没发现更多问题。

实际上让一部分处理页面的逻辑放到了前端来做，后台只负责输出数据，这种数据（XML），结构(XSLT)，表现(CSS)，行为(JS)4者相对分离的状态是十分有利于这个前端产业工业化发展的。随着前端工种的进一步细分，我觉得这里大有可挖。好处显而易见，如果要大面积改版（即便是小范围），由于后台只负责输出数据而没有HTML格式，高度分离的情况下，基本上只需要前端小组改一下即可。即便是对后台语言完全不了解都可以（我承认这不好）。
此外，xslt支持include/import等语句，包括上面提到的document()，可以很方便的实现页面各个部分的模块化。

但随之带来的问题也显而易见，数据过于结构化，页面内容轻易被人抓取而后分析（都不用分析……直接解析……）
此外，很多pda，手机之类的可能对xslt无法解析，但我估计屏幕阅读器应该没问题，因为很多屏幕阅读器都是基于现有浏览器的，也就是说现有浏览器支持，他也就支持。
还有上面提到的模块化问题，一不小心就可能导致连接数过多。每个模块的粒度得把握好。

解决这些问题的一个简单途径是，xml+xslt在服务器端解析生成。服务器端可以通过检测浏览器来判断直接输出xml+xslt还是输出生成的页面。这对于pda和手机之类的能提高很大兼容性。而对于一般浏览器又无需消耗服务器资源。
网上有篇流传甚广的文章XML在B/S架构开发中的应用，正是描述了此类情景。我考据下来可能是原著地址（我找到个更早的地址但上面的写的作者也是他，请宽恕我的网络考古情结）。

其中也提到了http://xml.apache.org/cocoon/ 似乎可以直接使用，没深究。

好了，得回到正题了。jQuer现在弄了个专门是放api的地址:http://api.jquery.com。说实话，我一直很不喜欢他现在弄的样子，当我需要在不同的方法之间切换的时候很不方便。有喜欢的可以自己尝试。另外，分析代码发现原来这个api也是从wiki里扣出来的xml进行解析得来的。另有air版，喜欢的可以自己下。扣的程序是Python 2.4写的，遗憾我这里只有Py3k环境，执行失败，且自己道行过浅，无法改成3.0版以供自己用。忘有此能力的同学能帮我改一下，可直接从jq的svn里拿到，点击下载。没有达人帮忙其实也没事，见到还有地址可以在线生成，前面在线生成的地址如果不加参数则可以直接查看这个生成器的文档。用urllib.request.urlretrieve(url,path)直接下载真的是很惬意的事情，Python真的是很强悍啊……
我随便写了个xslt，可以直接浏览jQuery 的英文文档。暂不提供下载，喜欢的就自己另存为吧……不喜欢的就自己写一套吧……
暂时计划是将中文文档转换成xml（这步已经在前天完成，转的我残念……请原谅我能力有限只能用这么离奇的办法转格式……）。不过之前写这个的时候还没有看到上面那个wiki2xml生成器（其实早就见过了，被我无视了而已……），所以对应的标签以及格式还不是很对上号。改天整整。另外，单个xml拆分成散件的xml的py脚本也写完了，实验成功，现在生成chm版的文档只差单文件xml的校对和chm文件的目录以及索引之类的编辑工作了。不用太期待……一揪回家了……新年饭局又多……饿……大半夜的吐槽可真不好……睡去了……