那么与状态相关的讨论在哪里呢？这个机制纸上谈兵还行，但是涉及到真正的值就不行了。进行调试时，我意识到验证测试的结果完全不可靠。例如，User ID 文本框被设计为接受除“Dino”和空字符串之外的任何内容。但是，它只对于常规回调运行正常，如果使用回调验证时就不行了。有些位置设置得很好的断点则显示所有文本框都保持了它们的原始值，而忽略了在尝试验证之前键入的内容。这个问题与视图状态无关，而是发布值的问题。页机制像平时一样运行正常；只是不能接收来自客户端且我认为正确的值。
如果您滚动查看使用 ASP.NET 回调的页的 HTML 源代码，就会发现在加载页时会调用一个名为 WebForm_InitCallback 的 JavaScript 函数。此函数是 ASP.NET 2.0 基础架构的一部分，它是通过 WebResource.axd 系统处理程序插入页面的。看一下此函数的源代码是否运行良好。（有关如何获得该代码的详细信息，请参阅上个月的专栏。）基本上，WebForm_InitCallback 在加载页时构建 POST 请求的正文。该页的正文是一个字符串（其名称为 __theFormPostData），其中填满了视图状态的内容以及窗体中的所有输入域。该代码是正确的；但是执行的时间不是我所预期的！这些输入域的内容是在加载时收集的，但是在进行回发时没有使用用户提供的值进行更新。这就是服务器状态看起来不正确的原因。为了解决此问题，我只是在开始带外调用之前重复了对 WebForm_InitCallback 的调用（请参见图 6）。请注意，这实际上是预期的行为，而不是什么错误。针对系统在带外调用之前调用 WebForm_InitCallback 的讨论是面向这样的情况的 — 即，用户希望在最初从服务器下发的数据上下文中执行回调。
返回页首
JavaScript 文件作为嵌入式资源
在该专栏的最后，我来讨论一个非常好用的技术，它大大简化了 ASP.NET 2.0 自定义控件中的 JavaScript 代码插入。该技术在 ASP.NET 1.x 中也能使用。其理念很简单：在常规 JS 文件中写入您的 JavaScript 代码，并将其作为嵌入式资源添加到项目中。（在 Visual Studio?.NET 属性窗口中设置 Build Action 属性）。另外，还要为资源名称添加该组件的命名空间作为前缀。接下来，当您需要在代码中使用该脚本时，请执行 EmbedScriptCode 方法在图 6中所作的操作。您使用一点技巧，就可以在代码维护和可读性方面收获很多。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
