在基于组件的 Web 框架中验证标记的最佳方法是什么?

发布于 2024-08-20 05:41:16 字数 1103 浏览 5 评论 0原文

如果您使用的是基于组件的(又名 Pull-based) Web 框架(例如 Tapestry、Wicket 等),如何确定您的标记通过了 W3C 验证?我想到了两种方法:

抓取正在运行的应用程序

专业版:

  • 验证所需的所有标记都存在于页面上。

缺点:

  • 要访问每个页面和每个案例可能会非常复杂。
  • 如果出现问题,可能并不明显是哪个组件导致了问题(尤其是在大型应用程序中)。
  • 您可能会一遍又一遍地验证同一组件(重复工作)。
  • 如果页面/组件很多,则可能需要很长时间。

离线抓取 HTML 模板

优点:

  • 您只需验证每个组件一次。
  • 如果您发现问题,您将确切地知道是哪个组件引起的。

缺点:

我能想到的大多数缺点都涉及丢失组件的上下文,因为您不会拥有页面的完整标记。

  • 您可能不知道给定组件的 DOCTYPE。
  • 可能很难知道组件的父组件是什么,这可能会导致问题。例如,检测包含块标签(例如

    )的内联标签(例如 )的无效情况代码>)。

  • 这些类型的框架中的 HTML 模板通常包含无法验证的无效属性和特殊符号(通常向框架指示某些内容)。

所以问题是,如果您使用基于组件的架构,如何验证您的标记?有没有推荐的技术,或者更好的工具来做到这一点?

编辑:我有点惊讶没有更多的答案。使用基于组件的框架时验证标记是否不常见?或者只是没有多少人使用它们?

If you're using a component-based (aka Pull-based) web framework (e.g. Tapestry, Wicket, et al), how do you determine that your markup passes W3C validation? Two approaches come to mind:

Crawl the running app

Pro:

  • All the markup required for validation exists on the page.

Cons:

  • Can be very complicated to hit every page and every case.
  • If something is wrong it may not be obvious which component is causing the problem (especially in large apps).
  • You may be validating the same component over and over again (duplicating effort).
  • It may take a very long time if there are many pages/components.

Crawl the HTML templates offline

Pros:

  • You only need to validate each component once.
  • If you find a problem you will know exactly which component is causing it.

Cons:

Most of the cons I can think of involve losing the context of the components because you won't have the full markup of a page.

  • You may not know the DOCTYPE for a given component.
  • It may be difficult to know what a component's parent is, which could lead to problems. E.g. Detecting the invalid case of an inline tag (e.g. <span>) containing a block tag (e.g. <form> or <p>).
  • HTML templates in these types of frameworks often contain invalid attributes and special symbols (usually to indicate something to the framework) that will not validate.

So the question is, if you're using a component-based architecture, how do you validate your markup? Are there any recommended techniques or, better yet, tools to do this?

EDIT: I'm a little surprised that there weren't more answers for this. Is it uncommon to validate your markup when using component-based frameworks? Or are there just not many people using them?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

深空失忆 2024-08-27 05:41:16

您确实希望使用完整的文档来完成大部分此类验证和测试。这可以确保您正在验证的内容确实是网络浏览器所看到的内容。

根据您必须验证的 URL 数量,一个不错的选择是使用 WDG 的批量验证器服务。

http://htmlhelp.org/tools/validator/batch.html.en

另外,wdg 和 w3c 有一个离线验证器,您可以将其与脚本一起使用来聚合测试结果。快速谷歌搜索会给你一些,如果你愿意的话,自己做起来并不困难。

您需要自己生成 url 列表,可以使用爬行脚本,也可以从数据库中生成。如果您的某些页面包含最终用户无法“破坏”的动态内容,则可以减少需要实际验证的页面数量。

You really want to do most of this type of validation and testing using the full served document. This assures that what you are validating is really what web browsers are seeing.

A good option for this depending on the number of urls you have to validate is to use the WDG's batch validator service.

http://htmlhelp.org/tools/validator/batch.html.en

Alternatively wdg and w3c have an offline validator that you can use with a script to aggregate the test results. A quick google search will give you a couple of them, and they aren't difficult to do yourself if you are so inclined.

You need to generate the list of url's yourself, either with a crawling script, or from your database. You can reduce the number of pages you have to actually validate if you have some pages with dynamic content that cannot be "broken" by your end users.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文