asp.net - Why do subcontrols initialize before their containers? -

despite working webforms years still find myself getting confused event lifecycle time time. isn't problem needs resolving, hoping better understanding of why things work way do.

suppose have form:

default.aspx:

<form>   <mycontrols:usercontrol1 runat="server"> </form> 

usercontrol1:ascx:

<mycontrols:usercontrol2 runat="server"> 

the oninit events occur in order:

usercontrol2_oninit usercontrol1_oninit default_oninit 

isn't bass-ackwards? shouldn't init code run in order controls created? shouldn't parent control able initialize properties of child before oninit runs? is, while can initialize properties of subcontrols in markup, there's no direct way have parent control able dynamically set properties of child control available oninit event.

what i've ended doing stuff this:

override void usercontrol2_oninit() {     namingcontainer.oninit += new evenhandler(usercontrol1_actualinit); } protected void usercontrol2_actualinit(..) {   // actual init code here, occur before onload after it's parent   // oninit } 

so it's not insurmountable problem. don't understand why it's problem in first place.

i realize perhaps might want able have child controls initialized in oninit code. fine, should able call base.oninit first, instead of after, own initialization code, should cause child control oninit events run. event lifecycle doesn't work way. init events not chained recursively, seem run independently parent events, , innermost 1 gets run first. seems life lot easier if chained recursively either call base event (or not) before thing in given situation. there i'm missing makes seemingly counterintuitive situation desirable or necessary?

the mindset asp.net parent & child controls is:

parents know children, children know nothing parent.

this mindset makes sense re-usable server controls. re-usability needs custom child control making no assumptions page gets used on.

the snippet give makes me guess child user controls not aimed @ re-usable such; rather specialized controls use break down complexities of large & tricky ui?

in case still try work 'children known nothing parent' mindset. think http://www.google.co.uk/search?q=gof+mediator+pattern parent page mediator between children (the wikipedia page good).

but children still need know parent right, because doing complex ui interactions? can address interfaces. each child depends not on parent, on interface defines children need access to. http://en.wikipedia.org/wiki/solid puts it, 'depend on abstractions, not on concretions'. 1 interface per child control: 'many client specific interfaces better 1 general purpose interface'

but ends looking over-engineered, doesn't it? turns out componentised ui components must interact, is complex, , components may turn out big n clunky. was, imho, 1 of reason ms web forms ajax controls losing out jquery &c. before mvc came along.

add web forms ui hard unit test; , confidence in software quality dives.

i recommend: if can, escape rewrite in mvc. if can't, consider abandoning server-side controls clientside behaviour, , use jquery instead. if can't that, simplify simplify simplify ui. if makes less functional. if don't want that, choices are: pay expense of engineering ui well; or pay expense of not engineering well.