J
jazzMan007
Hey All -
I'm working on a web site based on ASP.NET 2.0. Most of our major
controls are based off a copy of CompositeControl (we have a base
webcontrol class, and instead of putting all the base code into a
basecompositecontrol, I just used reflector to create a
CompositeControl that inherits from our base webcontrol class). We use
master pages for the whole site, which provide a header, navigation,
and main content area. In the content area is simply 1 composite
control, which then has any number of nested composite controls in it.
The CompositeControls are creating their UI by calling
Page.LoadControl(PathToAscxFile) in CreateChildControls, which is in
the base compositecontrol class, which then calls an abstract method
that is handled in the inheriting class to find and wireup the
controls.
The problem we're running into is trying to determine the lifecycle of
the controls. For instance, in OnLoad of one of the root controls, I
fetch data, call my overridden DataBind() to bind the data to the
controls. The first line in Databind is base.DataBind() since that
inherintly calls EnsureChildControls(), theoretically guaranteeing that
the controls are valid before I bind to them. Seemed like a good
pattern, however if any child control is designed using the same
pattern (fetch data in OnLoad, call DataBind() to ensure controls & set
their properties), their OnLoad is skipped because the base.DataBind()
in the parent made a call to DataBindChildren, so I'm hitting
DataBind() in the child control before it's OnLoad has run.
use the OnInit or OnLoad events to load data. Additionally, having
OnLoads skipped alltogether is pretty troubling. Should the entire
wireup of the control be based on CreateChildControls and nothing at
all in OnLoad/OnInit? Would it be a poor design to, say, explicitly
call EnsureChildControls early in the lifecycle (since setting some
properties could cause ChildControlsCreated to go back to false)? Or
does everything have to happen within the scope of CreateChildControls?
Can the rest of the page lifecycle be reliably used for anything?
Thanks in advance,
John
I'm working on a web site based on ASP.NET 2.0. Most of our major
controls are based off a copy of CompositeControl (we have a base
webcontrol class, and instead of putting all the base code into a
basecompositecontrol, I just used reflector to create a
CompositeControl that inherits from our base webcontrol class). We use
master pages for the whole site, which provide a header, navigation,
and main content area. In the content area is simply 1 composite
control, which then has any number of nested composite controls in it.
The CompositeControls are creating their UI by calling
Page.LoadControl(PathToAscxFile) in CreateChildControls, which is in
the base compositecontrol class, which then calls an abstract method
that is handled in the inheriting class to find and wireup the
controls.
The problem we're running into is trying to determine the lifecycle of
the controls. For instance, in OnLoad of one of the root controls, I
fetch data, call my overridden DataBind() to bind the data to the
controls. The first line in Databind is base.DataBind() since that
inherintly calls EnsureChildControls(), theoretically guaranteeing that
the controls are valid before I bind to them. Seemed like a good
pattern, however if any child control is designed using the same
pattern (fetch data in OnLoad, call DataBind() to ensure controls & set
their properties), their OnLoad is skipped because the base.DataBind()
in the parent made a call to DataBindChildren, so I'm hitting
DataBind() in the child control before it's OnLoad has run.
guarantee when CreateChildControls is called, hence, you can't reallyFrom what I've read online, when using CompositeControls, you can not
use the OnInit or OnLoad events to load data. Additionally, having
OnLoads skipped alltogether is pretty troubling. Should the entire
wireup of the control be based on CreateChildControls and nothing at
all in OnLoad/OnInit? Would it be a poor design to, say, explicitly
call EnsureChildControls early in the lifecycle (since setting some
properties could cause ChildControlsCreated to go back to false)? Or
does everything have to happen within the scope of CreateChildControls?
Can the rest of the page lifecycle be reliably used for anything?
Thanks in advance,
John