XML and XSLT 的大仙请进。

澳贼

原帖由 zn7726 于 2010-11-16 11:27 发表

那不成了asp / jsp 了吗

恩。为啥不呢？

dalaohu

i can't think of any good reason to use xslt for web pages.

xml should be only used in the backend service layer, and sending down html to the client.

乱码， 你是说你的网站客户访问的url 都是.xml extension的？

rogerk

原帖由 澳贼 于 2010-11-16 11:17 发表


web server 直接读数据库生成html岂不更好？？？

这就是业务层逻辑和表现层逻辑分开的分层。同样的数据可以render成不一样的presentation..你可以render城html,或者用rich client显示，或者被其他应用consume, 总之就是数据传过来了，格式也在xslt里面说明了，你照不照这个格式显示，是客户端的事情。

澳贼

原帖由 dalaohu 于 2010-11-16 11:46 发表
i can't think of any good reason to use xslt for web pages.

xml should be only used in the backend service layer, and sending down html to the client.

乱码， 你是说你的网站客户访问的url 都是.xml exten ...

若如此，xslt 岂不是毫无用处了。

澳贼

原帖由 rogerk 于 2010-11-16 11:47 发表


这就是业务层逻辑和表现层逻辑分开的分层。同样的数据可以render成不一样的presentation..你可以render城html,或者用rich client显示，或者被其他应用consume, 总之就是数据传过来了，格式也在xslt里面说明了，你照不照 ...

恩，有道理。缺点是大大增加了server的输出数据量？？

dalaohu

原帖由 澳贼 于 2010-11-16 11:49 发表


若如此，xslt 岂不是毫无用处了。

exactly, xslt 基本上就是个玩具。 基本没用。

rogerk

原帖由 乱码 于 2010-11-16 11:42 发表


对high traffic的website(我们现在的web site每个月的访问量将近30million),web layer和service layer是分开的，每个layer都有几个web farm，前面都有loader balancer,后面有若干nodes支持，web layer对service layer的a ...

当然，scalability也是一个原因，冗余，热备份或者load balance.

dalaohu

荒谬， server 把 xml + xslt 同时送到client ， 数据量大大 超出 render 好的html。

xslt 体积有多大， 你看看就知道了。

所以intetnet上根本没人则么做。

rogerk

原帖由 澳贼 于 2010-11-16 11:50 发表


恩，有道理。缺点是大大增加了server的输出数据量？？

这个就是trade-off阿，所以不是所有情况都一样的，得case by case的考察。

典

It's useful for
Some Offline devices / Offline web application,

[ 本帖最后由 典 于 2010-11-16 11:06 编辑 ]

rogerk

原帖由 dalaohu 于 2010-11-16 11:53 发表
荒谬， server 把 xml + xslt 同时送到client ， 数据量大大 超出 render 好的html。

xslt 体积有多大， 你看看就知道了。

所以intetnet上根本没人则么做。

当然大很多，但是并不是所有的应用都是internet上的。。跑在局域网上的web应用也很多。。

乱码

原帖由 dalaohu 于 2010-11-16 11:46 发表
i can't think of any good reason to use xslt for web pages.

xml should be only used in the backend service layer, and sending down html to the client.

乱码， 你是说你的网站客户访问的url 都是.xml exten ...

看来你没做过xslt，input是xml，xslt是工具，output是给browser的html

xslt不是output,我们是server side的xslt.

我们web layer expose出来的resource都是标准的.asp file

[ 本帖最后由 乱码 于 2010-11-16 12:01 编辑 ]

kawara

把XML转成HTML（special kind of XML），不是个特别好的主意。又复杂又慢，现在基本上已经不流行了。


但是做XML transfermation，xslt绝对是主力，另外一个是Xquery。主要用在系统集成上，特别是现在流行的SOA。

乱码

原帖由 rogerk 于 2010-11-16 11:47 发表


这就是业务层逻辑和表现层逻辑分开的分层。同样的数据可以render成不一样的presentation..你可以render城html,或者用rich client显示，或者被其他应用consume, 总之就是数据传过来了，格式也在xslt里面说明了，你照不照 ...

我们有version manager，跟据不同的地域，不用的要求，有render出不同的feel/look，但web service送到web layer的数据是相通的，只是用到不同的xslt template.

dalaohu

blizzard.com 以前page 都是 .xml 的。 后来也放弃了。

服务端的transformation，问我的话也绝对要用 xml -> class, 全部是strongly-typed
速度比xslt runtime transform不知要快多少。

xquery所有的语言都直接支持， 干吗要用最慢的xslt runtime执行？

rogerk

原帖由 乱码 于 2010-11-16 12:04 发表


我们有version manager，跟据不同的地域，不用的要求，有render出不同的feel/look，但web service送到web layer的数据是相通的，只是用到不同的xslt template.

是啊，这个就使业务逻辑和表现层逻辑分开的一个很好的例子。

dalaohu

另外, xquery 和 xslt 完全是两码事。

你们怎么好像把两则混为一谈了。

乱码

原帖由 dalaohu 于 2010-11-16 12:09 发表
blizzard.com 以前page 都是 .xml 的。 后来也放弃了。

服务端的transformation，问我的话也绝对要用 xml -> class, 全部是strongly-typed
速度比xslt runtime transform不知要快多少。

xquery所有的语言都直接支持，  ...

你说xslt不好写，我很同意，我也不喜欢，但如果说它performance有问题，那就不合适了。

下面是ms官方的文档：

“XSLT can be a very productive system that yields high-performance applications. For example, some big Web companies use XSLT as a way to generate HTML from XML that has been pulled from a variety of data stores. The managed XSLT engine compiles XSLT to CLR code, and performs even better in some scenarios than the native XSLT engine.”

http://msdn.microsoft.com/en-us/library/bb387048.aspx

乱码

原帖由 dalaohu 于 2010-11-16 12:19 发表
另外, xquery 和 xslt 完全是两码事。

你们怎么好像把两则混为一谈了。

xslt is nothing without xquery.

乱码

vs 2010引入和xlst 1.0 的debugger，在asp.net mvc中view也有专门针对xslt语法的engineer，还是有相当多的developer喜欢这个东西.

vs中如果没有web service proxy给你做deserialization,我想有80%现在用object的网站要用xslt来render html.

Don't take it for granted,我们要有感恩的心，有人给我们作heavy lifting的工作。

dalaohu

把一个相同的 xml load 测试。
你看一下结果把。

Having the following results:

XDocument: 00:00:08.2400000
XmlDocument: 00:00:12.6330000
XmlReader: 00:00:03.3510000
Xslt: 00:00:09.6800000

跟不用提， xslt 前期要花大量时间来写。XDoc是默认object， zero development time.

这个开发时间没法比的。

dalaohu

而且我做的话， 是直接xml load进 一个定义好的class 里， 比xdoc还要快。

dalaohu

原帖由 典 于 2010-11-16 11:57 发表
It's useful for
Some Offline devices / Offline web application,

I'd say it's useful for nothing. it's hard to develop, hard to maintain, and slow to run.

除非你先有的系统已经是基于xslt的。

对新人就根本不用推荐。

dalaohu

而且你把html也都写在 xslt里。 你的debug都有问题。

那些新的view engine，scaffolding, VS 提供的 intellisense你就全部享受不到了。
这个直接导致开发时间延长，日后维护困难， 你说是不是？

kawara

原帖由 乱码 于 2010-11-16 12:20 发表


xslt is nothing without xquery.

那是xpAth

dalaohu

原帖由 乱码 于 2010-11-16 12:28 发表
vs 2010引入和xlst 1.0 的debugger，在asp.net mvc中view也有专门针对xslt语法的engineer，还是有相当多的developer喜欢这个东西.

vs中如果没有web service proxy给你做deserialization,我想有80%现在用object的网站要 ...

这个概念也不对， WS proxy是deserial to object的， 不是来render的。

而且现在用Restful的话, cross-domain service, 走的都是json， js默认支持的。 js来render。 基本上没xslt任何事。

乱码

原帖由 dalaohu 于 2010-11-16 12:44 发表
而且你把html也都写在 xslt里。 你的debug都有问题。

那些新的view engine，scaffolding, VS 提供的 intellisense你就全部享受不到了。
这个直接导致开发时间延长，日后维护困难， 你说是不是？ ...

vs 2010 is able to debug xslt.

dalaohu

原帖由 乱码 于 2010-11-16 12:52 发表


vs 2010 is able to debug xslt.

那个是debug xslt 本身， 你里面embed的内容他不管的。

乱码

原帖由 dalaohu 于 2010-11-16 12:51 发表


这个概念也不对， WS proxy是deserial to object的， 不是来render的。

而且现在用Restful的话, cross-domain service, 走的都是json， js默认支持的。 js来render。 基本上没xslt任何事。 ...

你有点乱了。

我没说ws proxy是用来render的，deserialization的结果就是object.

我觉得我们在说两码事，我说的是server side xslt,你在说client side. 我们不用client side xslt，主要是
1. js可能没被打开。
2. performance issue.

乱码

原帖由 dalaohu 于 2010-11-16 12:56 发表

那个是debug xslt 本身， 你里面embed的内容他不管的。

他可以看到output，你做一下实验，不过input xml必须是file形式的，in memory block它不行。