关于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文件的目录以及索引之类的编辑工作了。不用太期待……一揪回家了……新年饭局又多……饿……大半夜的吐槽可真不好……睡去了……

《关于jQuery xml版英文文档的一些事》有5个想法

  1. 一个网站(像我的那样)如果完全采用XML+XSLT还有另外一个特别大的问题就是搜索引擎不抓了,即使抓了也不能很好的分析了,毕竟XML的是自解释的TAG.不过这个问题也要看怎么看了,是为了技术而作呢,还是为了搜索引擎而做或是为了内容或是为了其它服务什么的.

    像XSLT的浏览器支持情况,其实比起恐怖的CSS差异,已经是非常好了.并且实在不行就在服务器端进行XSLT,照样输出HTML,这样对于小网站可能见效不大,但对于大型项目,这种形式的模板化就比那些专门的模板引擎之类的要方便得多了,只是不知道服务器端的效率会如何.

  2. “很多时候所谓的css为了后期维护方便,可以任意修改布局而无需动页面结构之类的话语已经觉得难以置信了。我就不信有多少同学遇到过改版的时候只改css而不改html的”

    确实是…不过我觉得这个主要是开始的html没写好,而不是css的事

  3. @ 柠檬园主
    关于搜索引擎的问题我倒是没想到。不知道现在发展得怎么样了。但我觉得XML+XSLT解析总比AJAX得来的数据容易被爬虫捉住吧……

    另外,服务器端效率我觉得不用太担心,因为大多数浏览器都能自由访问,而仅对PDA和手机之类的才需要特殊对待,大多数情况下应该没问题的。我想专业的手机网站也不会用XML+XSLT来建的吧……

    1. 您搜索一下您的中文文档就知道对搜索引擎的友好程度了。
      或者直接在各个搜索引擎搜索 filetype:xml ,只在google中有结果。

      1. 看来对于SEO是个问题。但反过来这是相辅相成的互相促进的。用的人多了,自然搜索引擎公司会想办法支持的。这就跟flash对于SEO一直是个问题一样。但逐步在解决。我对此还是很乐观的。

发表评论