在我目前所进行的工作中，有个问题自从去年年中到现在已经发生了三次。一个Active Server Page (ASP)中包含有一个Design Time
Control (DTC)列表框，而这个列表框的内容是要依赖于另一个DTC列表框的选择。打个比方说，货运人要依赖于产品来源的制造厂，或者是用另一个更复杂的说法来解释：货运人要依赖于制造厂，而制造厂要依赖于消费者。这些依赖关系会使列表框之间的关系很快变得复杂起来。
目前的解决方案是创建一个服务器端JavaScript函数onchange()事件给每一个内容由另一个列表框的选择所决定的列表框。这个方案是可行的，但如果你不得不编写一个客户机端解决方案时，由于带宽的缺乏问题，它将变得更加复杂。我预想的解决方案将在客户机端更新DTC并只在表格被提交时才会涉及到服务器端。
由于DTC列表框只是一种使用HTML选项标签的方式，这个解决方案似乎很简单明了。我只花了几分钟编写一个服务器端函数来为有依赖性的列表框创建具有不同选项的隐藏HTML输入框。客户机端JavaScript函数来替换基于另一个DTC列表框的内容之上的列表框选项也很快地实现。页面中编码实现了页面在初始加载时有依赖性的列表框将是空的，他只在第一个列表框中做出选择时才会包含有选项。
第一次尝试非常的好，方案运行的很完美。从列表框选择一个选项导致了第二个选项的变动。我又试了几次感觉非常不错，接着，我点了提交按钮。服务器端对待依赖性DTC列表框就像它仍然是空的那样，这并不是我所期望的。
由于处在紧迫的期限之下，我简要地制定了一个权宜的解决方案：加入另一个隐藏的输入框来处理在依赖性DTC列表框中做出的选择。我很快地因为它的过度复杂而放弃了这个解决方案，这里需要的是一种一服务器端和一客户机端元素的解决方案。
寻找一个更好的解决方案的工作是从关注generated HTML开始的。很显然在客户机端缺少了某些东西，这是由一个很简单的变换的失败所导致的。
对由IIS产生的HTML进行的检查揭示了一些很有意思的事情：每一个DTC都有一个隐藏的输入框与其相关联。DTC就像冰山一样，只有在水平面之上的部分才能被看到，我错误地假定HTML列表框全是可见的且改变可见的对象就足够了。
ASP引擎使用这些隐藏输入框来保持状态，这样如果页面被刷新，而选择将会保留，列表框DTC反映了在相关列表框中可用的选项。这里是我的代码种的问题：它只作了部分的工作，对于位于水平面之下的列表框的更新是必要的。有了这个知识，我已经做好了再一次尝试更新客户机端的DTC列表框的准备。
扩展DTC的更多途径
查找如何扩展DTC的方法，请看减少服务器流量。
