fonctionnant autour de la génération d'ID de contrôle ASP.NET 3.5: événements de publication lorsque les contrôles sont créés dans un ordre différent lors des publications suivantes

Question

Je travaille sur un système de commentaire pour un site Web et à chaque publication une page génère un contrôle utilisateur (appelé ucComment) pour chaque commentaire de la base de données relatif à cette page. Chaque ucComment possède un bouton Répondre qui vous permet de répondre à chaque commentaire individuel. J'ai eu un problème avec le bouton Répondre ne faisant rien quand j'ai finalement réalisé que chaque fois qu'un nouveau commentaire a été créé, la prochaine publication, il compenserait tous les ID de contrôle de la page. En d'autres termes, lorsque je clique sur ctl00_Content_ctl00_ctl01_ctl0 _lbtnRespond, que le contrôle serait effectivement généré comme ctl00_Content_ctl00_ctl01_ctl0 _lbtnRespond sur la prochaine publication. Donc, l'événement associé à ctl07 ne se produirait tout simplement pas.

Tout en fouinant sur le web, j'ai lu sur la redéfinition de l'ID client. Je pensais que si je pouvais nommer les contrôles comme je le voulais, je pourrais contourner mon problème. http://west-wind.com/Weblog/posts/4605.aspx Cela ressemblait à un super hack mais il ne déclenche pas d'événements en raison de la disparité entre l'ID généré sur la page et la façon dont l'ID a été représenté dans l'arborescence de contrôle.

il y a même un gars qui dérive de MasterPage de changer la façon dont l'arbre de commande fonctionne pour obtenir le hack ci-dessus pour travailler pour postbacks: http://www.netquarry.com/index.php/2009/03/master-pages-ajax-and-javascript-10292/ mais je crains qu'il peut y avoir des répercussions incalculables.

Que dois-je faire pour que mon système de commentaires fonctionne de sorte que je puisse répondre à un commentaire spécifique et déclencher l'événement response même si le contrôle est renommé sur cette publication?

Answer 1

Je suis le gars de NetQuarry qui a travaillé sur la classe dérivée de MasterPage.

Je ne sais pas si vous avez résolu votre problème ou non. Je peux certainement comprendre votre préoccupation au sujet de mon approche MasterPage. Je craignais que cela ne soit aussi fragile. Cependant, cela fonctionne bien depuis environ un an et demi sur une demi-douzaine d'applications Web différentes qui sont construites sur notre plate-forme. Cela dit, comme ils sont tous construits sur notre plate-forme, ils ont certaines similitudes. Le code a également continué à fonctionner sans problème lorsque nous sommes passés de .Net 2.0 à .Net 3.5.

Récemment cependant, nous avons trouvé que l'approche ne fonctionne pas avec UpdatePanels et n'ont pas été en mesure de remédier à la situation. Pendant que je faisais des recherches sur ce problème, j'ai découvert que .Net 4.0 fournit un meilleur contrôle sur les ID client que .Net 3.5 et je pense qu'avec 3.5, il sera assez simple de réparer ce genre de chose. Voici un bon article de Scott Guthrie à ce sujet:

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: juste pour moi que dans ce cas, votre problème pourrait être résolu en rendant simplement chaque bouton Respond commentaire avec un identifiant unique basé sur la clé primaire de l'enregistrement de commentaire associé. De cette façon, sur une publication, l'ID de chaque bouton existant ne change jamais.

Espérons que cela soit utile.

Cam

Answer 2

Avez-vous une chance de publier le code côté serveur utilisé pour générer les contrôles utilisateur? Et la page aspx qui les héberge?