使用 XML 和 XSLT 构建网站是一个好主意吗?

6
我在想,使用XML文档作为网页内容并使用XSLT来管理显示部分而不是使用纯HTML,是否会带来优势或劣势。
在我看来,第一个条件是浏览器对XML和XSLT的支持。但据我所知,现代浏览器都没有问题。(如果我错了,请纠正我。)
但是,例如在语义网络等方面是否存在好处,或者在搜索引擎排名方面是否存在损失(HTML标签更常见)?
您是否认为有其他原因应该或不应该使用XML和XSLT的组合来制作网页?
相关:
为什么选择XSL转换?
创建使用XSLT的站点有意义吗?
11个回答

6

个人而言,我不会经常使用客户端 xslt; 这种方法存在浏览器支持的问题,以及您可能需要剥离xml中的数据(即客户端不需要知道或不应该知道的数据)。

但是在服务器端...几年前,我经常使用这种方法作为VB6的MVC实现——即VB6代码(控制器)将数据收集为xml(模型),并使用xslt来构造html(视图)。在关注点分离方面表现良好。如今,我会使用ASP.NET MVC执行相同的操作,但使用ascx / aspx视图模板。


+1. 我在几个网站中使用XML和XSLT,每个转换都在服务器端完成,因此我不必担心浏览器支持的问题。唯一的问题是它不能让人们使用语义化Web工具。有时,我会通过默认发送HTML文件,但允许使用明确的URL获取XML源来解决它。 - bortzmeyer

5
这是一个非常重要的话题。10年前,人们开始问这个问题......我们能否将数据包发送到浏览器并让浏览器呈现内容?这个设计目标之所以如此重要,是为了解决我们今天面临的问题......多种类型的设备和平板电脑不完全支持浏览器的桌面模型。XHTML已经带领我们走了很远......现在ECMAScripting是人们正在尝试创建的东西。但从长远来看,它是一个非常糟糕的模型。它打破了在Web上重新使用标记和内容的目标。
答案是肯定的......你可以构建XSL / XSLT / XML类型的系统。您可以发送一组XML数据包,并附带其XSLT样式表的链接,使大多数(如果不是全部)现代浏览器将文件解析为客户端标记。我已经做过了,它的速度非常快。
现在小组提到的缺点是真实存在的。存在浏览器如何解析XSLT,然后呈现脚本元素和缓存过期XML等问题。与设计团队进行交互以及学习将内容、设计和结构抽象成这些类型的片段也存在真正的问题。但这是Web的真正长期目标,也是XSL被设计成这样的原因。它的力量在于分离结构、数据和设计,从而使服务器和客户端都能摆脱锁定在设计元素中的内容奴役。编译并层叠到UI中的Javascripted解决方案并没有帮助,而是使情况变得更糟,因为标记设计和数据经常混在一起。我鼓励所有新的Web开发人员开始考虑XSLT / XML解决方案,因为最终目标是能够将XML数据传递到超出桌面浏览器之外的各种客户端。如果您有为整个不同设备设计的XSLT / CSS,并且除了缓存之外只发送XML到客户端,则拥有一个非常简单,快速且强大的重用数据传递系统,可以超越当前基于桌面应用程序/桌面浏览器的网站所提供的,并引入一个真正可扩展和强大的数据传递时代。因此,我说是的,请尝试使用XSLT!

4

2

您应该在服务器端进行转换,而不是依赖于浏览器支持。

我们使用它来支持网站上的多种语言。缺点是有时候我们的设计师需要花费很长时间才能学会使用XSL / XSLT / XPATH 设计页面。


1

(由于我还不能评论,所以这是作为对“圣松鼠”的回复)

实际上,您可以在XSL中使用ASP.NET控件,而且非常简单。只需将asp命名空间添加到XSL中,将转换为字符串编写器,然后解析转换后的字符串中的控件即可:

// Transform
xsltrans.Transform(xmldoc, xslArg, oSW);

// Get transformed content
string sPage = oSW.ToString();

// Add to page
Page.Controls.Clear();
Page.Controls.Add(Page.ParseControl(sPage));

这将解析转换后内容中的任何ASP.NET控件。


0

我从未听说过其他人这样做,但我使用XSLT作为基于XML的HTML模板语言的宏语言。我不使用它进行大规模的文档转换,而是用于定制标签。在编译模板之前,模板会通过xslt运行,因此它永远不需要实际操作数据。它提供的是一种尽可能简洁地使用xml片段的方法,然后执行非常简单的转换,以以一种在模板语言本身中不可能或至少更难以实现的方式输出代码。

对于html,通常需要嵌套div并添加类等,只是为了使其看起来正确,而没有添加任何真正的含义。而不是在各个地方重复该模式,很容易只创建一个自定义元素,然后编写一个简单的XSLT转换,将该元素及其属性转换为完全展开的html。但是,我绝不会梦想着仅使用XSLT作为模板化数据的唯一手段。太麻烦了。


0

XHTML是HTML的XML版本。我可能会避免在网站上使用XSLT。我会使用XHTML和CSS来控制呈现方式。我这么说是因为(X)HTML/CSS几乎是Web应用程序的事实标准,而且有许多可用于开发和调试的工具。

如果您想利用XHTML中的一些非理想的HTML内容,则有不同级别的XHTML验证。


0

这是一种不错的做法,但不幸的是许多服务器端技术都不支持这个想法。

例如,在ASP.NET中,您不能使用服务器控件来实现这种方法,这通常足以让人们望而却步。

XSLT非常适用于没有交互的页面,如报告等。


0

如果将其与服务器端代码的强大相比较,XSLT在多个参数上表现不佳。

如果您的页面完全是动态的,仍然值得在服务器端代码中创建它。如果您的数据源是XML,则仍然可以使用服务器端XML解析和转换来创建转换后的XHTML并将其提供给客户端。

通常不必完全依赖浏览器的能力,在客户端独立地转换HTML。大多数现代浏览器都具有良好的XML / XSLT支持,但它们的主要区别在于所使用的XSLT处理器类型。


0

有时候我会使用XML,当一个网站没有MySQL数据库或者只需要记录一小组需要经常更改的项目时,我会使用它,并使用PHP将其解析到我的带有HTML/CSS的网页中。

然而,这需要手动编辑每个XML条目,所以只适用于小型应用程序。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接