User Controls: Did I go Nuts?

[Robert Howells]

Perhaps I'm just too new at this to pull it off, or perhaps it's just bad
architecture. I'd appreciate some feedback on the the wisdom (or lack
thereof) in attempting the following:

I'm not new to programming, but I am new to ASP.NET and Web application
design in general... loved the concept of user controls and dynamically
adding them to a page. So what I wound up with was an application that
dynamically loads two user controls directly onto an aspx page (inserted
into PlaceHolder controls); and one of those user controls then dynamically
loads a third user control which itself declaratively implements three
additional user controls (net result is three user controls dynamically
loaded at runtime; with one of them nested within the other; the nested one
declaratively implements three additional user controls: for a total of six
user controls: three loaded dynamically and three loaded declaratively).
*Each* user control and the aspx page use C# code-behind modules and each
hits a database to determine or retrieve (1) which user controls to load,
(2) data to show up on each, and (3) property settings for various Web
Server controls that appear on the user controls. Mind you, these user
controls are not simply small snippets. While some do not take up much
screen real-estate, each implements a certain amount of non-trivial
code-behind logic. Everything loads just fine with and with remarkable
performance considering all that's going on behind the scenes. But I think
the party has come to an end now that I'm trying to deal with saving data
back to the database. I had this grand vision of having a button on the aspx
page (not in one of the user controls) that would trigger a postback. That
works, but grabbing property values from the server controls that appear
*within the dynamically loaded* user controls is not exactly
straight-forward. I've seen plenty of tutorials on referencing a user
control from the hosting aspx page's code-behind, but things are quite
different when the user controls are (1) nested and (2) dynamically loaded
onto the page. A thread last week mentioned that dynamically loaded user
controls must be added on each successive request (Postbacks included). I
took this to mean that there is no control to which to even get a reference
during the postback - and therefore no way to read property values from Web
Server controls that exist within the dynamically loaded user controls. I
tried a few things, but eventually gave up on that approach and figured that
the Forms collection would bail me out - but it won't because it doesn't
expose all the important property values of the Web Server controls that
appear within the dynamically loaded user controls.

So, at this point I'm perfectly willing to dump this whole thing and start
over with a different design - one that omits dynamically loading user
controls that host server controls to which I'll need complete access on
Postback. Anyway, as I head off to do this redesign, I'm just wondering to
what extent I went overboard. It would certainly help me up the learning
curve (from an architectural perspective) to hear some feedback from some of
you who have implemented non trivial dynamic Web Applications.

Thanks.

[Hans Kesting]

"Robert Howells" <[e-mail]> wrote in message news:em******** ******@tk2msftn gp13.phx.gbl...

Perhaps I'm just too new at this to pull it off, or perhaps it's just bad
architecture. I'd appreciate some feedback on the the wisdom (or lack
thereof) in attempting the following:

I'm not new to programming, but I am new to ASP.NET and Web application
design in general... loved the concept of user controls and dynamically
adding them to a page. So what I wound up with was an application that
dynamically loads two user controls directly onto an aspx page (inserted
into PlaceHolder controls); and one of those user controls then dynamically
loads a third user control which itself declaratively implements three
additional user controls (net result is three user controls dynamically
loaded at runtime; with one of them nested within the other; the nested one
declaratively implements three additional user controls: for a total of six
user controls: three loaded dynamically and three loaded declaratively).
*Each* user control and the aspx page use C# code-behind modules and each
hits a database to determine or retrieve (1) which user controls to load,
(2) data to show up on each, and (3) property settings for various Web
Server controls that appear on the user controls. Mind you, these user
controls are not simply small snippets. While some do not take up much
screen real-estate, each implements a certain amount of non-trivial
code-behind logic. Everything loads just fine with and with remarkable
performance considering all that's going on behind the scenes. But I think
the party has come to an end now that I'm trying to deal with saving data
back to the database. I had this grand vision of having a button on the aspx
page (not in one of the user controls) that would trigger a postback. That
works, but grabbing property values from the server controls that appear
*within the dynamically loaded* user controls is not exactly
straight-forward. I've seen plenty of tutorials on referencing a user
control from the hosting aspx page's code-behind, but things are quite
different when the user controls are (1) nested and (2) dynamically loaded
onto the page. A thread last week mentioned that dynamically loaded user
controls must be added on each successive request (Postbacks included). I
took this to mean that there is no control to which to even get a reference
during the postback - and therefore no way to read property values from Web
Server controls that exist within the dynamically loaded user controls. I
tried a few things, but eventually gave up on that approach and figured that
the Forms collection would bail me out - but it won't because it doesn't
expose all the important property values of the Web Server controls that
appear within the dynamically loaded user controls.

So, at this point I'm perfectly willing to dump this whole thing and start
over with a different design - one that omits dynamically loading user
controls that host server controls to which I'll need complete access on
Postback. Anyway, as I head off to do this redesign, I'm just wondering to
what extent I went overboard. It would certainly help me up the learning
curve (from an architectural perspective) to hear some feedback from some of
you who have implemented non trivial dynamic Web Applications.

Thanks.

I think you are on the right track. Dynamically loading controls does make life
simpler in some ways.

Some remarks:
* creating the controls on postback: if you want your control to receive postback
events (button click etc), then it should exist at that point. So on the first request
you generate a page with your control, then the user clicks a button that is linked
to a server-side handler. This triggers a second request where you have to make
sure your control is again added to the page (in Page_Load or before) before
it can receive the "click message" to fire the event.
* single "save all" button: I think the best way is to derive all your controls (that you
want to respond to that "save event") from a special baseclass. This baseclass
at least has an abstract "save" method (might also be implemented and virtual).
When the "save all" button is clicked (in the page the click eventhandler is called)
then you recursively loop through all controls in the page, searching for controls
that implement your baseclass. Then you can cast to that baseclass and call
the save method.

Hans Kesting