Control level communication

[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?

[CompiledMonkey]

So, I came up with another solution I think works a lot better.

Effectively I've created a user control out of each composite control.
I can still use event/delegate communication, only, the events are
handled in the Page instead of the individual user controls. It seems
to make a lot of sense doing it that way. Everything is handled in one
spot, you can attach a number of listeners to an event, and it's a
clean way to attach communication versus sending loose messages all
over.And it sure is nice to have direct HTML access to my controls
instead of worrying about programmatically doing everything. The one
negative is that a lot of ".FindControl()" action is going on and cross
user control development is going on. I guess given the needs of my
application that isn't a huge deal.

Thoughts on my approach?



CompiledMonkey wrote:

> 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?