C
CompiledMonkey
I'm building a set of custom server controls that need to perform
certain actions based on state. So, when a button is clicked in server
control 1, I'd like to call a method from server control 2.
I had considered developing a master control that contains references
to each of the children controls so these objects would be available to
reference, but it doesn't seem all that great to have to drag the host
of controls you want on the screen and then another control that's just
the parent of the children. From a consuming developer's perspective
it seems like an unnecessary step.
It also seems feasible to have design-time strings of the child control
IDs that I can use. But, communication is likely to go both ways. The
child may trigger an event that the parent needs to respond to and so
forth. So that can get messy quickly.
My last thought would be to use events/delegates as it seems like a
strong foundation for handling communication between the different
controls. So as a test I've created two composite controls. One of
which is a ToolbarControl that has a delegate/event sequence. I then
created a WebUserControl just as a palette for the two composite
controls. So I dropped those in and registered the event in the
ToolbarControl within the code behind for the WebUserControl. When
that event fires and is caught by the WebUserControl code behind I am
able to reference the other composite control directly and manipulate
it's properties as needed. All in all it sounds like a decent solution
although I'm not sure it's the best.
Can anyone foresee issues that may arise from this architecture? Has
anyone run into something like this in the past? What worked for you?
certain actions based on state. So, when a button is clicked in server
control 1, I'd like to call a method from server control 2.
I had considered developing a master control that contains references
to each of the children controls so these objects would be available to
reference, but it doesn't seem all that great to have to drag the host
of controls you want on the screen and then another control that's just
the parent of the children. From a consuming developer's perspective
it seems like an unnecessary step.
It also seems feasible to have design-time strings of the child control
IDs that I can use. But, communication is likely to go both ways. The
child may trigger an event that the parent needs to respond to and so
forth. So that can get messy quickly.
My last thought would be to use events/delegates as it seems like a
strong foundation for handling communication between the different
controls. So as a test I've created two composite controls. One of
which is a ToolbarControl that has a delegate/event sequence. I then
created a WebUserControl just as a palette for the two composite
controls. So I dropped those in and registered the event in the
ToolbarControl within the code behind for the WebUserControl. When
that event fires and is caught by the WebUserControl code behind I am
able to reference the other composite control directly and manipulate
it's properties as needed. All in all it sounds like a decent solution
although I'm not sure it's the best.
Can anyone foresee issues that may arise from this architecture? Has
anyone run into something like this in the past? What worked for you?