La liaison de données bidirectionnelle de contrôles dans un contrôle utilisateur imbriqué dans un FormView ne fonctionne pas

Question

J'essaie d'effectuer une liaison de données bidirectionnelle sur les contrôles de mon contrôle utilisateur, qui est hébergé dans un modèle FormView:

<asp:ObjectDataSource runat="server" ID="ObjectDataSource" 
    TypeName="WebApplication1.Data" SelectMethod="GetItem" UpdateMethod="UpdateItem"> 
</asp:ObjectDataSource> 
<asp:FormView runat="server" ID="FormView" DataSourceID="ObjectDataSource"> 
    <ItemTemplate> 
     <uc:WebUserControl1 runat="server"></uc:WebUserControl1> 
    </ItemTemplate> 
    <EditItemTemplate> 
     <uc:WebUserControl1 runat="server"></uc:WebUserControl1> 
    </EditItemTemplate> 
</asp:FormView> 

le contrôle utilisateur Web:

<%@ Control Language="C#" ... %> 
<asp:TextBox runat="server" ID="TitleTextBox" Text='<%# Bind("Title") %>'> 
</asp:TextBox> 

les travaux liseréest lorsque le FormView est en mode Affichage mais quand je passe en mode Edit, sur appel UpdateItem sur le FormView, les liaisons sont perdues. Je le sais parce que FormView essaie d'appeler une méthode de mise à jour sur ObjectDataSource qui n'a pas d'argument appelé 'Title'.

J'ai essayé de résoudre ceci en implémentant IBindableTemplate pour charger les contrôles qui sont dans mon contrôle utilisateur, directement dans les modèles (comme si je les avais déclarés de manière déclarative). Toutefois, lorsque vous appelez UpdateItem en mode édition, le container qui est transmis à la méthode ExtractValues du modèle ne contient plus le TextBox. Il a fait en mode vue!

J'ai trouvé des questions sur SO qui se rapportent à ce problème mais elles sont plutôt datées et elles ne fournissent aucune réponse qui m'a aidé à résoudre ce problème.

Comment penses-tu que je pourrais résoudre ce problème? Il semble que ce soit une simple exigence, mais apparemment c'est tout sauf ça ...

Answer 1

Ma solution de contournement actuelle pour cela est, bien que plutôt lourde, de sous-classer la classe FormView et d'utiliser des contrôles sous-classifiés, implémentant ma propre logique de liaison de données (en prenant le nom du champ de données d'une nouvelle propriété) au lieu d'utiliser la syntaxe <%# %>. Apparemment, le code que ce dernier génère est le vrai coupable car il ne supporte pas ce scénario de contrôle imbriqué.

Answer 2

Je fini, en utilisant ancienne asp comprennent la déclaration

< -% include file = "nom de fichier" ->

au lieu d'utiliser les contrôles utilisateur pour traiter la question de la duplication de code .