12

Closed

Databinding inside TabPanel

description

When using a databound textbox inside a Tabpanel in the EditItemTemplate of a FormView, the new value in the ItemUpdating event of the formview is always null, no matter what I enter in the textbox.
As a result, my database values are also getting updated to null.
Displaying the initial value however, poses no problems. Only when updating the values, they become null.

In the attached file, you will find a small example.

file attachments

Closed Jun 1, 2007 at 11:50 PM by
This actually isn't a TabContainer issue, it's just how ASP.NET does it's databinding. Since TabContainer is an INamingContainer, when code generation happens for DataBinding it tries to do something like:

FindControl("txtName").Text = DataItem.TextField;

Well that won't work because "txtName" doesn't exist within the naming scope of the FormView or other Container.

I can repro this scenario by replacing TabContainer with LoginView and putting everything into the <AnonymousTemplate>. Same thing happens.

comments

wrote Feb 16, 2007 at 7:24 PM

Assigning to kirti to see if repro is valid.

markusg wrote Mar 9, 2007 at 8:44 AM

Same problem here,

see also http://forums.asp.net/AddPost.aspx?PostID=1580131

mhurdle wrote Mar 20, 2007 at 7:00 PM

I'm getting the same problem when trying to change the properties of a button in a FormView that's in a TabPanel in the code behind.

urbanlen wrote Apr 6, 2007 at 11:58 PM

Solution of this problem is important for meBecause I have situations where I want to Insert/Update formview fields from two o three tabpanel and have one Update/Insert button outside de tabpanel/tabcontainer to make update of the content of all the tabs at the same time. I know, I can make anything to solve this problem in code behind, but I think this is very important, elementary property of this control.and it should work without patches in code behind and strange things.It misses me "Impact Low ", have you any solution:)?I like this control but this bug limits its functionality a lot,thank you for any answer.

kdp80 wrote May 6, 2007 at 3:50 PM

I also have this issue with tabs and formview. Hosting a set of tabs within a formview is a basic and critical need of many developers. I used a formview, bound to a datasource control. Within the formview there is an EditItemTemplate that contains a Tabcontainer with a set of tabs. I bound many controls (textboxes, dropdownlists, etc.) within the tabs to the datasource fields. The fields are successfully bound to the controls on load and display the data without issues, however debugging an attempt to postback and update the values show thats the datasource sees null or empty strings ("") for all fields. It is as though it cannot find the tab container and it's child controls.

The basic structure and problem is easy to reproduce: ' runat="server"/> .....

bmild wrote May 24, 2007 at 8:58 PM

I have a problem with databinding a repeater (with DataSourceID) inside of a TabPanel. I was able to workaround using the old codebehind approach.

wrote May 26, 2007 at 12:55 AM

I am assigning this to Shawn for investigation. Shawn - I have attached a repro file. Attempt to perform an update. Since the items are inside a tabcontainer they are unable to find the datasource set on its parent. What it is the right syntax around this? I am not sure.Something like Parent["ObjectDataSource1"].Title. Could you please take a look. I do not think this is a Toolkit issue. We just need to get the naming container usage straightened out.


See TabContainerUpdatePanel.aspx for repro.

kdp80 wrote Jun 8, 2007 at 4:00 PM

So what is the suggested work-around? The functionality is obviously not acceptable, regardless of who is to blame. Manually binding every field is obviously not a viable solution.

gjactat wrote Jun 27, 2007 at 4:32 PM

OK... The answer from Shawnburke explains us why this doesn't work... Anyway it doesn't help.Splitting big forms among several views (MultiView, TabPanels or even Wizard Steps) is a standard need.So, what can we do if none of the existing controls (standard ASP.Net or AjaxControlToolkit) can help us ?

I can see two ways to deal with the problem :- Using code behind to bind manually UI fields and DB object properties (heavy...)- Splitting the formview in many formviews (this means adding Update Methods that deal with some of the fields). Each TabPanel gets one and only one FormView that covers some of the parameters.

Is it possible to add a new TabPanel behavior so that it doesn't change the inner objects naming ?...

MWFolz wrote Aug 2, 2007 at 5:50 PM

Actually, I cannot quiet follow the explanations Shawnburke is giving to us. After reading his comment on closing the issue today, which more or less states the problem would be strongly related to the naming of the controls, I tried to figure that one out.

So I hacked the TabContainer and TabPanel source code, removing the inheritance of INamingContainer. To be more precise, I dubbed the class ScriptControlBase to ScriptControlBaseHack and removed the inheritance of INamingContainer right there.

As a result, the control IDs are behaving just like expected: where we had "formview1.tabcontainer1.tabpage1.textbox1" before, now there is a plain "formview1.textbox1". Everything else seems to work just like before: I've tried the recompiled Ajax sample pages as well as my own stuff.

But still, the data binding is only working one-way: the data is correctly bound on read, but on update it will still not find any of the controls within the TabPage.

This is strange, because Shawnburke is telling as that ASP.NET is using function simular to FindControl("textbox1") to identify the controls. But with my hack, formview1.FindControl("textbox1") is working properly, because "textbox1" actually does exist in the naming scope of the FormView control.

It must be something different.

kkyriako wrote Aug 18, 2007 at 8:24 AM

So what is the work around I don't undertand. Issues like this one make me regret the first day I laid my hands on the control toolkit. This is a critical issue and needs to be resolved.

MWFolz wrote Aug 18, 2007 at 11:13 PM

@kkyriako: there is not workaround. I just pointed out I cannot follow the explanation Shawnburke was providing us: it is not, as far as I do understand, a problem with INamingContainer.

And, yes, problems like that cost me a lot of time (and thus money). The "workaround" I followed was throwing all ASP.NET FormView controls out of my project and replacing them by a true AJAX solution we've created because of the problems we experienced with the tab container.

I do not regret the latter, because that solution works quite good, at least faster than the original FormView. But of course I question myself: why should I use a framework like ASP.NET Ajax when in the end you have to code integral parts by yourself? By now I think we'd been better off choosing one of the dozens of free Ajax frameworks available instead of ASP.NET Ajax Control Toolkit.

kkyriako wrote Aug 21, 2007 at 3:22 AM

I agree that such issues cause a lot of frustration. But I firmly belive that for every problem there is a solution. Since Control Toolkit is an open source project I expect it to be influenced by what the public thinks and not following microsoft guidlelines. Regarding the issue with the INamingContainer that particular interface is what it is and if microsoft does not want to modify it so be it. However, why does the Control Toolkit community cannot create a IFlatNamingContainer that will contain controls without forcing hierarchical naming convention. And why in addition to the TabPanel the TabContainer cannot include FlatTabPanel that does not alter the names of their controls. Why not extend that behaviour to all Ajax Controls that are containers of other controls.

A better solution would be for The Ajax Control Toolkit to implement a single instance of the INamingContainer that can be configure by a parameter to either provide flat or hierarchical namespace. In that case the TabPanel could be configure as

MWFolz wrote Aug 21, 2007 at 1:21 PM

I already did what you suggested. I created a IScriptControl class not inheriting INamingContainer and based the TabContainer on that class. But that, as I pointed out in my post on Aug 02, did not resolve the data binding issue (thus producing "flat names"; as you call it).

To resolve the issue, one must have a look into the FormView control source code to understand how databinding is done there. But that control is not published as open source, and we - the "community" - do not have access to the source code. Under these circumstances I see no chance to fix the problem for somebody not having access to the ASP.NET source code.

mrjimmy wrote Sep 5, 2007 at 5:40 AM

I just spent several hours trying to make this work, then I searched and found this thread. Since they know about it, why the hell don't they add it as a "known issue" at the bottom of the control toolkit page for this control - like they do for the ValidatorCallout control? I wasted so many hours on this :<

Sign in to add a comment