代码之家  ›  专栏  ›  技术社区  ›  okoman

对网站使用xml和xslt是个好主意吗?

  •  4
  • okoman  · 技术社区  · 17 年前

    我想知道当使用xml文档来管理web页面的内容和xslt来管理显示部分而不是使用纯html时,它是否带来了优势或劣势。

    在我看来,第一个条件是浏览器支持xml和xslt。但据我所知,没有一款现代浏览器有这个问题。(如果我错了,请纠正我。)

    但是,在搜索引擎的排名中,有没有好处(语义web等等)或损失(html标记更常见)?

    或者您是否看到了为什么应该或不应该将xml和xslt结合用于web页面的其他原因?

    相关:

    Why choose an XSL-transformation?

    Is there a point creating a site using XSLT

    11 回复  |  直到 14 年前
        1
  •  5
  •   Marc Gravell    17 年前

    我个人不会用 客户端 xslt非常常见;浏览器支持方面存在问题,而且您可能需要去掉xml中的数据(即客户机不需要知道或不应该知道)。

    但服务器端…几年前,我经常使用这种方法作为VB6的MVC实现,也就是说,VB6代码(控制器)将数据收集为XML(模型),并使用XSLT来塑造HTML(视图)。在关注点的分离方面,它工作得很好。这些天我会使用asp.net mvc来做同样的事情,但是使用ascx/aspx视图模板。

        2
  •  5
  •   Mitch Stokely    14 年前

    这是一个非常重要的话题。10年前,人们开始问这个问题……我们能把数据包发送到浏览器并让浏览器渲染内容吗?设计目标如此重要的原因是为了解决我们今天面临的问题……多种类型的设备和平板电脑不完全支持桌面模式的浏览。到目前为止,xhtml已经把我们带到了……现在人们正试图创建ecmascript来做这样的事情。但从长远来看,这是一个非常糟糕的模式。它打破了在web上重新调整标记和内容用途的目标。

    答案是肯定的……可以构建XSL/XSLT/XML类型系统。您可以发送一个XML包和一个链接到它的XSLT样式表,并且如果不是所有的现代浏览器都将大多数文件解析成客户端上的标记。我做到了,它的工作速度快得难以置信。

    现在小组提到的撤回是真实的。浏览器如何解析xslt,然后呈现脚本元素和缓存过时的xml等方面存在问题。与设计团队交互,以及学习将内容、设计和结构抽象到这些类型的片段中存在实际问题。但这是Web长期的真正目标,以及为什么XSL是按它的方式设计的。它的功能是分离出结构、数据和设计,并使服务器和客户机从锁定在设计元素中的内容的奴役中解放出来。编译并分层到ui中的javascripted解决方案并没有起到帮助作用,反而使它变得更糟,因为标记设计和数据常常被网格化在一起。我将鼓励所有新的web开发人员开始考虑xslt/xml解决方案,因为最终目标是能够专注于将xml数据传递给桌面浏览器以外的所有客户机。如果您的xslt/css是为大量不同的设备设计的,而xml只是发送给您的客户机的缓存之外的所有内容,那么您就拥有了一个非常简单、快速、功能强大的数据传递系统,它超越了当前基于桌面应用程序/桌面浏览器的网站所提供的功能,为网络带来一个真正可扩展和强大的数据交付时代。所以,我说可以,试试xslt!

        3
  •  4
  •   Jack Brown    15 年前

    下面是一个基于xsl的网站示例。

    http://www.skechers.com

    足够说

        4
  •  2
  •   PQW    17 年前

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

    我们使用它来支持我们网站上的多种语言。缺点是,有时我们的设计人员在使用xsl/xslt/xpath设计页面时有一个陡峭的学习曲线。

        5
  •  1
  •   PQW    17 年前

    (因为我无法评论,但这是对“Saint Gerbil”的回答。

    实际上,您可以在XSL中使用ASP.NET控件,它非常简单,将命名空间ASP添加到XSL中,将转换转换为String写入器,然后解析转换后的字符串中的控件:

    // 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
  •  0
  •   Andy White    17 年前

    xhtml是html的xml版本。我可能会避免在网站上使用xslt。我将使用xhtml和css来控制演示。我之所以这么说,是因为(x)html/css实际上是web应用程序的标准,而且还有许多工具可用于开发和调试。

    如果您想在xhtml中利用一些不理想的html内容,那么对xhtml的验证有不同的级别。

        7
  •  0
  •   Mark Broadhurst    17 年前

    这是一种很好的方法,但不幸的是,很多服务器端技术都不支持这种想法。

    例如,在asp.net中,这种方法通常足以关闭用户,因此不能使用服务器控件。

    xslt非常适合那些没有交互的页面,比如报表。

        8
  •  0
  •   Cerebrus    17 年前

    如果将它与服务器端代码的威力进行比较,xslt在几个参数上就有缺陷。

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

    很少有必要完全依赖浏览器的功能在客户机上独占地转换html。大多数现代浏览器都有很好的xml/xslt支持,但它们的主要区别在于所使用的xslt处理器的类型。

        9
  •  0
  •   Anriëtte Myburgh    17 年前

    我有时确实使用XML,因为当一个网站没有MySQL数据库或只是记录一个小的项目数组(需要更改很多),然后使用PHP在我的网页中用HTML/CSS解析它。

    但是,这确实需要手动编辑每个xml条目,所以只需将其用于小型应用程序。

        10
  •  0
  •   Dario    17 年前

    我不得不在我的主页上使用客户端xsl(t),以防止Freehoster自动插入广告;-)(IE和Firefox对此有问题!)

    我会在服务器端使用xml,但除了普通的xhtml+css之外,从不传输任何东西。对互联网来说,一切都是建立在一种技术上的,而不是数千种个人语言和语义。

        11
  •  0
  •   Russell Leggett    16 年前

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

    在html中,通常需要嵌套div和添加类等,以便在不添加任何实际意义的情况下使其看起来正确。不必到处重复这种模式,只需创建一个自定义元素,然后编写一个简单的xslt转换来获取该元素及其属性并将其转换为完全扩展的html就很容易了。然而,我从来没有想过使用xslt作为数据模板的唯一方法。太多毛了。