对网站使用 XML 和 XSLT 是个好主意吗?
Posted
技术标签:
【中文标题】对网站使用 XML 和 XSLT 是个好主意吗?【英文标题】:Is it a good idea to use XML and XSLT for websites? 【发布时间】:2010-10-25 18:58:08 【问题描述】:我想知道当使用 XML 文档作为网页内容并使用 XSLT 管理显示部分而不使用纯 html 时,它是否会带来优势或劣势。
在我看来,第一个条件是浏览器支持 XML 和 XSLT。但据我所知,没有任何现代浏览器存在问题。 (如果我错了,请纠正我。)
但是在搜索引擎的排名中是否有好处(语义网等)或损失(HTML标签更常见)?
或者您是否看到其他原因,为什么应该或不应该在网页中使用 XML 和 XSLT 的组合?
相关:
Why choose an XSL-transformation?
Is there a point creating a site using XSLT
【问题讨论】:
【参考方案1】:我个人不会经常使用 clientside xslt;浏览器支持存在问题,并且您可能在 xml 中有需要删除的数据(即客户端不需要知道或不应该知道)。
但是服务器端...几年前,我经常使用这种方法作为 VB6 的 MVC 实现 - 即 VB6 代码(控制器)将数据收集为 xml(模型),并使用 xslt 来塑造html(视图)。它在关注点分离方面效果很好。这些天我会使用 ASP.NET MVC 来做同样的事情,但使用 ascx/aspx 视图模板。
【讨论】:
+1。我对几个站点使用 XML 和 XSLT,并且每次转换都是在服务器端完成的,因此我不必关心浏览器的支持。唯一的问题是它不允许人们使用语义网工具。有时,我通过默认发送 HTML 文件来解决这个问题,但允许使用显式 URL 获取 XML 源。【参考方案2】:这是一个非常重要的话题。 10 年前,人们开始问这个问题......我们可以向浏览器发送数据包并让浏览器呈现内容吗?设计目标如此重要的原因是为了解决我们今天面临的问题......不完全支持桌面浏览模式的多种设备和平板电脑。 XHTML 已经把我们带到了这么远......现在人们正在尝试创建 ECMAScripting 来做这样的事情。但从长远来看,这是一个非常糟糕的模型。它打破了网络上标记和内容的再利用目标。
答案是肯定的......您可以构建 XSL/XSLT/XML 类型系统。您可以发送一个 XML 数据包并带有指向其 XSLT 样式表的链接,并且大多数(如果不是全部)现代浏览器将文件解析为客户端上的标记。我已经完成了,它的运行速度令人难以置信。
现在小组提到的缺点是真实的。浏览器如何解析 XSLT,然后渲染脚本元素和缓存陈旧的 XML 等存在问题。与设计团队的接口以及学习将内容、设计和结构抽象为这些类型的部分存在真正的问题。但这是 Web 长期的真正目标,也是 XSL 设计成这样的原因。它的力量在于分离结构、数据和设计,并将服务器和客户端从锁定在设计元素中的内容奴役中解放出来。 javascripted 解决方案,编译并分层到 UI 中,并没有帮助反而使情况变得更糟,因为标记设计和数据通常是网格在一起的。我会鼓励所有新的 Web 开发人员开始考虑 XSLT/XML 解决方案,因为最终目标是能够专注于将 XML 数据交付给桌面浏览器之外的大量客户端。如果您拥有为大量不同设备设计的 XSLT/CSS,并且除了缓存之外发送给客户端的所有内容都是 XML,那么您将拥有一个非常简单、快速且功能强大的再利用数据交付系统,它超越了当前桌面应用程序/基于桌面浏览器的网站现在给了我们,并为网络带来了一个真正可扩展和强大的数据交付时代。所以,我说是的,试试 XSLT!
【讨论】:
【参考方案3】:这是一个基于 xsl 的网站示例。
http://www.skechers.com.
说得够多了
【讨论】:
【参考方案4】:您应该在服务器端进行转换,而不是依赖浏览器支持。
我们使用它来支持我们网站上的多种语言。缺点是有时我们的设计师在使用 XSL/XSLT/XPATH 设计页面时学习曲线陡峭。
【讨论】:
【参考方案5】:(由于我无法发表评论,因此这是对“圣格比尔”的回复)
其实你可以在 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 控件。
【讨论】:
【参考方案6】:XHTML 是 HTML 的 XML 版本。我可能会避免将 XSLT 用于网站。我会使用 XHTML 和 CSS 来控制演示。我这样说是因为 (X)HTML/CSS 几乎是 Web 应用程序的事实标准,而且还有更多工具可用于开发和调试。
如果您想利用 XHTML 中的一些非理想 HTML 内容,则 XHTML 有不同级别的验证。
【讨论】:
【参考方案7】:这是一种很好的做事方式,但不幸的是很多服务器端技术不支持这个想法。
例如,在 ASP.NET 中,您不能通过这种方法使用服务器控件,这通常足以让人们失望。
XSLT 非常适合没有像报告这样的交互的页面。
【讨论】:
【参考方案8】:如果将其与服务器端代码的功能进行比较,XSLT 在几个参数上都存在不足。
如果您的页面完全是动态的,那么在服务器端代码中创建它仍然是值得的。如果您的数据源是 XML,您仍然可以使用服务器端 XML 解析和转换来创建转换后的 XHTML 并将其提供给客户端。
很少需要完全依赖浏览器的功能在客户端上专门转换 HTML。大多数现代浏览器都具有良好的 XML/XSLT 支持,但它们的主要区别在于使用的 XSLT 处理器的类型。
【讨论】:
【参考方案9】:我有时会使用 XML,因为当网站没有 mysql DB 或仅用于记录一小部分项目(需要大量更改)时,然后使用 php 在我的网页中使用 HTML 解析它/CSS。
但是,这确实需要您手动编辑每个 xml 条目,因此只需将其用于小型应用程序。
【讨论】:
【参考方案10】:我不得不在我的主页上使用客户端 XSL(T) 来防止 freehoster 自动插入广告 ;-)(IE 和 Firefox 有这个问题!)
我会在服务器端使用 XML,但只传输纯 XHTML+CSS 之外的任何东西。互联网至关重要的是,一切都建立在一种技术中,而不是数千种个人语言和语义。
【讨论】:
【参考方案11】:我从未听说过其他人这样做,但我使用 XSLT 作为一种宏语言,用于基于 XML 的 html 模板语言。我不将它用于从一个文档到另一个文档的大规模转换,而是用于本质上的自定义标签。模板在编译之前通过 xslt 运行,因此它不需要实际操作数据。然而,它提供的是一种尽可能简洁地使用一段 xml 的方法,然后执行一个非常简单的转换以输出代码,这种方式在模板语言本身中是不可能的,或者至少更难做到。
对于 html,通常需要嵌套 div 和添加类等,只是为了让它看起来正确而没有添加任何实际意义。无需到处重复该模式,只需创建一个自定义元素,然后编写一个简单的 XSLT 转换来获取该元素及其属性并将其转换为完全扩展的 html,这很容易。但是,我永远不会梦想使用 XSLT 作为模板化数据的唯一方法。毛茸茸的。
【讨论】:
以上是关于对网站使用 XML 和 XSLT 是个好主意吗?的主要内容,如果未能解决你的问题,请参考以下文章
使用 ionic 构建网站的移动 Web 版本是个好主意吗? [关闭]
在 Angular7 应用程序中使用 ComponentFactoryResolver 是个好主意吗?
当站点的用户注销或登录时,`session_destroy()` 是个好主意吗?