Composite Controls with a data driven child contro

Devilzhangout

New Member
I am building a Composite Control that takes a different direction from the MSDN documentation.<BR>My control adds different child controls based on data coming from properties and other objects in the application. MSDN's docs seem to focus on creating a fixed list of controls. Thus CreateChildControl() is hardcoded with particular Controls getting created and added to the Controls list.<BR><BR>In my case, I have two types of data:<BR>1. Data that describes which controls to build. (Example: A Sql Table's field list and associated field properties.)<BR>2. Data to assign to the controls and later retrieve from them. (Example, data stored in the same table.)<BR><BR>My problem is with the Post Back functionality. It calls CreateChildControls() before a page's Page_Load() method is called. MSDN states that the Page_Load method is where you attach your data sources to your controls. That works fine for a new page, because CreateChildControls() is called after Page_Load(). For a Post Back, CreateChildControls() is called before Page_Load() to gather post back and View State data.<BR><BR>In my control, I have put all the control generation in CreateChildControls(). To get it to work on Post Back, I have attached my data source during the page's OnInit method. But this is a hack which limits the usefulness of this control because the programmer can no longer customize the control in Page_Load.<BR><BR>The following strategy occurs to me.<BR>On a new page load:<BR>- Make CreateChildControls() do nothing. This is safe since we don't need the controls for LoadViewState and ProcessPostData.<BR>- Add a DataBind() which actually creates the controls. This allows the user to establish all properties and attach the datasource. As each element is created, ViewState is recorded to help reconstitute the structure on Post Back. (This is a concern since the number of elements can be quite large. Sessions are an alternative but lose their data after the session times out.)<BR>- User must call DataBind() in Page_Load.<BR><BR>During a post back load:<BR>- CreateChildControls() generates the controls from data preserved by the earlier call to DataBind(). This establishes the correct control structure for LoadViewState() and ProcessPostBack() to be applied to each child.<BR>- User must not call DataBind in Page_Load unless they want to overwrite the post back values.<BR>- When the datasource is attached in Page_Load, the Save function has some way to connect the control to the appropriate data element.<BR><BR>This design makes things quite difficult. There are two entirely different functions to create the controls list (a maintenance and debugging nightmare). The data source for assigning field values needs to work differently for loading vs. saving:<BR>Loading has the data source while it creates each control in DataBind(). It knows exactly which data element is associated with the control.<BR><BR>Saving (via Post Back) has a bunch of controls that have no clear markers to the originating data element. This needs to be resolved.<BR><BR>I'd like a good and potentially Microsoft recommended strategy for this situation.<BR><BR>Thanks!<BR><BR>--- Peter Blum<BR>[email protected]
 
Back
Top