Two-way data binding of controls in a user control nested inside a FormView doesn't work

Question

I'm trying to perform two-way data binding on the controls in my user control, which is hosted inside a FormView template:

<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>

The web user control:

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

The binding works fine when the FormView is in View mode but when I switch to Edit mode, upon calling UpdateItem on the FormView, the bindings are lost. I know this because the FormView tries to call an update method on the ObjectDataSource that does not have an argument called 'Title'.

I tried to solve this by implementing IBindableTemplate to load the controls that are inside my user control, directly into the templates (as if I had entered them declaratively). However, when calling UpdateItem in edit mode, the container that gets passed into the ExtractValues method of the template, does not contain the TextBox anymore. It did in view mode!

I have found some questions on SO that relate to this problem but they are rather dated and they don't provide any answers that helped me solve this problem.

How do you think I could solve this problem? It seems to be such a simple requirement but apparently it's anything but that...

EDIT: My current workaround for this is, although rather cumbersome, to subclass the FormView class and use subclassed controls in it, implementing my own data binding logic (taking the data field name from a new property) instead of using the <%# %> syntax. Apparently, the code the latter generates is the real culprit here as it doesn't support this nested control scenario.

I'm still very interested in a better solution however.