Обход генерации идентификатора элемента управления ASP.NET 3.5: события обратной передачи, когда элементы управления создаются в другом порядке при последующих обратных передачах

Question

Я работаю над системой комментариев для веб-сайта, и при каждой обратной передаче страница генерирует пользовательский элемент управления (называемый ucComment) для каждого отдельного комментария в базе данных, относящейся к этой странице. Каждый ucComment имеет кнопку «Ответить», которая позволяет вам отвечать на каждый отдельный комментарий.

У меня была проблема с тем, что кнопка Ответить ничего не делала, когда я наконец понял, что каждый раз, когда создается новый комментарий, при следующей обратной передаче он смещает все контрольные идентификаторы страницы. Другими словами, когда я нажимаю ctl00_Content_ctl00_ctl01_ctl0 7 _lbtnRespond, этот элемент управления будет фактически сгенерирован как ctl00_Content_ctl00_ctl01_ctl0 8 _lbtnRespond при следующей обратной передаче. Таким образом, событие, связанное с ctl07, просто не произойдет.

Пока я бродил по сети, я читал о переопределении ClientID. Я подумал, что если бы я мог назвать элементы управления так, как я хотел, я мог бы обойти мою проблему. http://west -wind.com / Weblog / сообщений / 4605.aspx Это выглядело как отличный хак, но не генерирует события из-за несоответствия между сгенерированным идентификатором на странице и тем, как идентификатор был представлен в дереве элементов управления.

есть даже один парень, который заимствовал из MasterPage, чтобы изменить способ, которым работает дерево элементов управления, чтобы заставить вышеуказанный хак работать для постбэков: http://www.netquarry.com/index.php/2009/03/master-pages-ajax-and-javascript-10292/ но я боюсь, что могут быть неисчислимые последствия.

Что я должен сделать, чтобы моя система комментирования работала так, чтобы я мог отвечать на конкретный комментарий и чтобы событие ответа продолжало срабатывать, даже если элемент управления переименован в этой обратной передаче?

Answer 1

Я - парень из NetQuarry, который работал над классом, производным от MasterPage.

Я не знаю, решили ли вы свою проблему или нет. Я, конечно, могу понять вашу озабоченность по поводу моего подхода к MasterPage. Я был обеспокоен тем, что это может быть и хрупким. Тем не менее, он работает уже около полутора лет на полдюжине различных веб-приложений, созданных на нашей платформе. Тем не менее, поскольку они все построены на нашей платформе, у них есть определенное сходство. Код также продолжал работать без проблем, когда мы перешли с .Net 2.0 на .Net 3.5.

Однако недавно мы обнаружили, что подход не работает с UpdatePanels и не смогли исправить ситуацию. Исследуя эту проблему, я обнаружил, что .Net 4.0 обеспечивает намного лучший контроль над ClientID, чем .Net 3.5, и я подозреваю, что с 3.5 будет довольно просто исправить подобные вещи. Вот хорошая статья Скотта Гатри об этом:

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

Редактировать: Мне только что пришло в голову, что в этом случае ваша проблема может быть решена простым рендерингом каждой кнопки ответа на комментарий с уникальным идентификатором, основанным на первичном ключе соответствующей записи комментария. Таким образом, при обратной передаче идентификатор каждой существующей кнопки никогда не меняется.

Надеюсь, это полезно.

Cam

Answer 2

Есть ли шанс, что вы сможете опубликовать код на стороне сервера, используемый для создания пользовательских элементов управления?А на странице aspx, в которой они находятся?