解决 ASP.NET 3.5 控件 ID 生成问题：在后续回发中以不同顺序创建控件时的回发事件
我正在为一个网站开发一个评论系统，并且在每次回发时，页面都会为数据库中与该页面相关的每一条评论生成一个用户控件（称为 ucComment）。每个 ucComment 都有一个“回复”按钮，允许您回复每个单独的评论。
当我最终意识到每次创建新评论时，下一次回发都会抵消页面的所有控件 ID 时，我遇到了“响应”按钮不执行任何操作的问题。换句话说，当我单击 ctl00_Content_ctl00_ctl01_ctl07_lbtnRespond 时，该控件实际上会在下一次回发时生成为 ctl00_Content_ctl00_ctl01_ctl08_lbtnRespond。因此与 ctl07 相关的事件根本不会发生。
在网上浏览时，我读到了有关覆盖 ClientID 的内容。我想如果我能按照我想要的方式命名控件，我就可以解决我的问题。 http://west-wind.com/Weblog/posts/4605.aspx 它看起来像是一个很棒的 hack，但它不会触发事件，因为页面上生成的 ID 与 ID 在控制树中的表示方式之间存在差异。
甚至还有一个人从 MasterPage 派生来更改控制树的工作方式，以使上述 hack 能够用于回发： http://www.netquarry .com/index.php/2009/03/master-pages-ajax-and-javascript-10292/ 但我担心可能会产生难以言喻的后果。
我应该怎么做才能让我的评论系统正常工作，以便我可以响应特定评论，并且即使在该回发时重命名控件，响应事件仍然会触发？
I'm working on a commenting system for a website and on each postback a page generates a user control (called ucComment) for every single comment in the database that pertains to this page. Each ucComment has a Respond button that allows you to respond to each individual comment.
I was having a problem with the Respond button not doing anything when I finally realized that every time a new comment was created, the next postback it would offset all the page's control IDs. In other words, when I click on ctl00_Content_ctl00_ctl01_ctl07_lbtnRespond, that control would actually be generated as ctl00_Content_ctl00_ctl01_ctl08_lbtnRespond on the next postback. So the event associated with ctl07 would simply not happen.
While poking around on the web, I read about overriding the ClientID. I thought if I could name the controls the way I wanted to, I could circumvent my problem.
http://west-wind.com/Weblog/posts/4605.aspx
It looked like a great hack but it doesn't fire events because of the disparity between the generated ID on the page and how the ID was represented in the control tree.
there's even a guy who derived from MasterPage to change the way that the control tree works to get the above hack to work for postbacks:
http://www.netquarry.com/index.php/2009/03/master-pages-ajax-and-javascript-10292/
but i fear that there may be untold repercussions.
What should I do to get my commenting system working such that I can respond to a specific comment and have the respond event still fire even if the control is renamed on that postback?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我是 NetQuarry 开发 MasterPage 派生类的人。
不知道你的问题解决了没。我当然可以理解您对我的 MasterPage 方法的担忧。我担心它也可能很脆弱。然而，它已经在我们平台上构建的大约六种不同的 Web 应用程序上运行良好大约一年半了。也就是说，由于它们都是在我们的平台上构建的，因此它们确实有一定的相似之处。当我们从 .Net 2.0 迁移到 .Net 3.5 时，代码也可以继续正常工作。
然而最近，我们确实发现该方法不适用于 UpdatePanels，并且无法纠正这种情况。在研究这个问题时，我发现 .Net 4.0 比 .Net 3.5 提供了更好的对 ClientID 的控制，我怀疑在 3.5 中修复此类问题会非常简单。这是 Scott Guthrie 的一篇关于此的好文章：
http://weblogs.asp.net/scottgu/archive/2010/03/30/cleaner -html-markup-with-asp-net-4-web-forms-client-ids-vs-2010-and-net-4-0-series.aspx
编辑：我刚刚想到在这种情况下，您的问题可以通过简单地根据相关评论记录的主键使用唯一的 ID 呈现每个评论响应按钮来解决。这样，在回发时，每个现有按钮的 ID 永远不会改变。
希望这会有所帮助。
凸轮
I'm the guy at NetQuarry that worked up the MasterPage-derived class.
I don't know if you've solved your problem or not. I can certainly understand your concern about my MasterPage approach. I was concerned that it might be fragile as well. However, it's been working well now for about a year and half on about half a dozen different web applications that are built on our platform. That said, since they're all built on our platform, they do have certain similarities. The code also continued to work without issue when we moved from .Net 2.0 to .Net 3.5.
Recently however, we did find a that the approach does not work with UpdatePanels and have not been able to remedy the situation. While researching that problem I discovered that .Net 4.0 provides much better control over ClientID's than .Net 3.5 and I suspect that with 3.5 it will be pretty simple to fix this kind of thing. Here's a good article from Scott Guthrie about this:
http://weblogs.asp.net/scottgu/archive/2010/03/30/cleaner-html-markup-with-asp-net-4-web-forms-client-ids-vs-2010-and-net-4-0-series.aspx
Edit: It just occurred to me that in this case your problem might be solved by simply rendering each comment respond button with a unique ID based on the primary key of the related comment record. That way on a postback the ID of each existing button never changes.
Hope this is helpful.
Cam
您有机会发布用于生成用户控件的服务器端代码吗？以及托管它们的 aspx 页面？
Any chance you could post the server side code used to generate the user controls? And the aspx page that hosts them?