In a great deal of sample code, including the quick start, databinding is done declaratively with a data source object on the page and the DataSourceID property set to the data source. In simple databinding scenarios, the DataSource property is set in code and the DataBind method is called. However, if you want to use advanced capabilities such as sorting, filtering, paging or CRUD actions then the simple databinding falls apart. Then comes advanced databinding, wiring up the OnNeedDataSource event with the DataSource property. I've been able to get this to work but I've found that I can no longer call Page.DataBind without various bad side effects happening in my grid. Other controls on the page need to be databound. How does one resolve the two techniques, especially if the grid is in a user control and other controls on the page must be bound using the binding syntax (<%# %>)?
Thanks,
Kevin
Thanks,
Kevin
4 Answers, 1 is accepted
0
Todd Anglin
Top achievements
Rank 2
Rank 2
answered on 27 Mar 2009, 08:09 PM
Hello Kevin-
In general, I don't think you should need to make direct calls to Page.DataBind(). In all my years of ASP.NET dev, I've never need to call this method manually. What is the root reason that you are using this approach? Are you using <%# %> instead of <%= %> to avoid errors about modifying the controls collection? If so, there may be some better workaounds that help you avoid the need to call Page.DataBind. Check out these resources and see if they help:
Let me know if this helps at all. If it does not, we can talk in more detail about how your NeedDataSource is structured. Hope that helps.
-Todd
0
Kevin
Top achievements
Rank 2
Rank 2
answered on 27 Mar 2009, 10:45 PM
Thanks for the quick response!!! This was helpful for my specific case. I'm a noob and don't know the best patterns to use for this.
From the NeedDataSource event documentation we have:
"Important: You should never call Rebind() method in NeedDataSource event handler or DataBind() for the grid at any stage of the page lifecycle!"
From a design perspective it seems a bit fragile, like the comment from the link you provided. if I'm putting my grid into a user control how can I prevent any Control.DataBind or Page.DataBind calls from recursively calling my grid's DataBind method during the Page or Control's lifecycle. Or does it matter? The page is doing it, I'm not calling it. But I think I've seen problems with this in certain cases. Looking for a workaround. There must be a way to trap it. I don't think
public override void DataBind()
{
base.DataBind();
}
in the user control code-behind will prevent databind from recursively going to the grid.
From the NeedDataSource event documentation we have:
"Important: You should never call Rebind() method in NeedDataSource event handler or DataBind() for the grid at any stage of the page lifecycle!"
From a design perspective it seems a bit fragile, like the comment from the link you provided. if I'm putting my grid into a user control how can I prevent any Control.DataBind or Page.DataBind calls from recursively calling my grid's DataBind method during the Page or Control's lifecycle. Or does it matter? The page is doing it, I'm not calling it. But I think I've seen problems with this in certain cases. Looking for a workaround. There must be a way to trap it. I don't think
public override void DataBind()
{
base.DataBind();
}
in the user control code-behind will prevent databind from recursively going to the grid.
0
Todd Anglin
Top achievements
Rank 2
Rank 2
answered on 27 Mar 2009, 11:12 PM
In general, you do not want to call DataBind manually when you're using NeedDataSource because the Grid will do it automatically (or implicitly). When you call it manually, you're just risking "double-data binding" your Grid. For most application scenarios, this should be fine. I have constructed many complex applications with RadGrid and the NeedDataSource method and this has always proved reliable.
An alternative- one that I actually perfer- is to bind your Grid to an ObjectDataSource. The ObjectDataSource enables you to expose your business logic via a Data Source control, which can simplify things like binding, paging, etc. without putting a lot of code in your code behind's NeedDataSource event. Better Speration of Concerns, in other words.
Try some of these suggestions (and those in the articles I linked to) and let me know if you have any additional questions. Enjoy your weekend!
-Todd
0
Kevin
Top achievements
Rank 2
Rank 2
answered on 30 Mar 2009, 10:25 PM
The reason I point out the problem with DataBind is that the grid is being placed inside of a reusable control, AddressGridModule.ascx. If some other control, or the containing page calls DataBind then recursion sets in and the grid's DataBind method will be called regardless of what I do in the control.
The ObjectDataSource has a few problems.
That being said, I'm doing some experiments with it to see if it solves my problems until I can refactor this.
The ObjectDataSource has a few problems.
- it doesn't cache the reflected methods.
- there is a bug associated with the UI Culture
- it throws away the underlying object after each call, making it expensive data-wise.
- using it in Web Site applications plays havoc if the namespaces aren't correct
The type specified in the TypeName property of ObjectDataSource 'AddressesDataSource' could not be found
That being said, I'm doing some experiments with it to see if it solves my problems until I can refactor this.