Wrapping Composite Controls
-
HI Guys - I'm working on an application that has a number of discrete sections to its user interface. These sections are defined in terms of what they display, what methods can be performed on them, and what events are raised. Ideally, i'd like to put all the discrete sections into standalone controls, which can be dumped into the application shell and managed using an event driven observer model. The problem i am facing is that in some instances i am using Trees, and i'm trying to achieve the following: * Have a hierachial instance of objects that represent my data. * Traverse and manipulate the data tree * Keep the TreeViews synchronised with this data * Hide the TreeViews / TreeNodes from any calling code (It's already wrapped in a composite control). Are there any good patterns to do this? Has anyone encountered this kind of problem before, and have experience solving it? Cheers Tris
------------------------------- Carrier Bags - 21st Century Tumbleweed.
-
HI Guys - I'm working on an application that has a number of discrete sections to its user interface. These sections are defined in terms of what they display, what methods can be performed on them, and what events are raised. Ideally, i'd like to put all the discrete sections into standalone controls, which can be dumped into the application shell and managed using an event driven observer model. The problem i am facing is that in some instances i am using Trees, and i'm trying to achieve the following: * Have a hierachial instance of objects that represent my data. * Traverse and manipulate the data tree * Keep the TreeViews synchronised with this data * Hide the TreeViews / TreeNodes from any calling code (It's already wrapped in a composite control). Are there any good patterns to do this? Has anyone encountered this kind of problem before, and have experience solving it? Cheers Tris
------------------------------- Carrier Bags - 21st Century Tumbleweed.
Tristan Rhodes wrote:
Are there any good patterns to do this?
Yes. Most of these patterns can found in the GOF book. Of course you should start with a MVC design and then add other patterns into that design like the Command pattern for example. With these patterns the UI components are completely isolated from the work the application does and become observers of events triggered by the operations of the system so they can maintain a valid display to the user. Does that sound like what you were asking about?
-
Tristan Rhodes wrote:
Are there any good patterns to do this?
Yes. Most of these patterns can found in the GOF book. Of course you should start with a MVC design and then add other patterns into that design like the Command pattern for example. With these patterns the UI components are completely isolated from the work the application does and become observers of events triggered by the operations of the system so they can maintain a valid display to the user. Does that sound like what you were asking about?
I think i made a bad decision at the start of the app. As i had no stand alone tree structure that raises change events, i implemented a derived tree and handled all the change events via the host form. Unfortunately, now that i have 3 seperate views of the same data, it would be more desirable to have the data seperate and give a handle to each of the controls to make it self synchronising (Via a property or something). Would this be a good way to go? Or should the model be linked to the Observer, and that keep things synchronised with the views? Additionaly, is it common practice to nest observers? i.e. Would you have an observer to keep three tree views and a tree model synchronised, then another observer to manage the Tree Model + the rest of the application? Just playing with ideas on where to go in the future. Cheers Tris
------------------------------- Carrier Bags - 21st Century Tumbleweed.
-
I think i made a bad decision at the start of the app. As i had no stand alone tree structure that raises change events, i implemented a derived tree and handled all the change events via the host form. Unfortunately, now that i have 3 seperate views of the same data, it would be more desirable to have the data seperate and give a handle to each of the controls to make it self synchronising (Via a property or something). Would this be a good way to go? Or should the model be linked to the Observer, and that keep things synchronised with the views? Additionaly, is it common practice to nest observers? i.e. Would you have an observer to keep three tree views and a tree model synchronised, then another observer to manage the Tree Model + the rest of the application? Just playing with ideas on where to go in the future. Cheers Tris
------------------------------- Carrier Bags - 21st Century Tumbleweed.
Tristan Rhodes wrote:
Or should the model be linked to the Observer, and that keep things synchronised with the views?
Do you know MVC? If not start with the Wikipedia page for it. In MVC, Views subscribe to notifications from the Model.
Tristan Rhodes wrote:
Additionaly, is it common practice to nest observers? i.e. Would you have an observer to keep three tree views and a tree model synchronised, then another observer to manage the Tree Model + the rest of the application?
Not sure what all that means, perhaps you are overusing "tree". There is no reason to be specific about User Interface Tree Control. Just generalize that to Views, period. What each view does to manage any controls it may own is it's business. When the user interacts with the UI, the UI handler passes the message to the Controller in MVC. It is the Controller that coordinates that message into whatever system services pertain to that operation. Any one event may result in Model notification messages being sent. Using that design is how you might synchronize different views. Also other patterns can be used to implement synchronization like an extended Command Pattern to contain command state information. Does that help?
-
Tristan Rhodes wrote:
Or should the model be linked to the Observer, and that keep things synchronised with the views?
Do you know MVC? If not start with the Wikipedia page for it. In MVC, Views subscribe to notifications from the Model.
Tristan Rhodes wrote:
Additionaly, is it common practice to nest observers? i.e. Would you have an observer to keep three tree views and a tree model synchronised, then another observer to manage the Tree Model + the rest of the application?
Not sure what all that means, perhaps you are overusing "tree". There is no reason to be specific about User Interface Tree Control. Just generalize that to Views, period. What each view does to manage any controls it may own is it's business. When the user interacts with the UI, the UI handler passes the message to the Controller in MVC. It is the Controller that coordinates that message into whatever system services pertain to that operation. Any one event may result in Model notification messages being sent. Using that design is how you might synchronize different views. Also other patterns can be used to implement synchronization like an extended Command Pattern to contain command state information. Does that help?
Hi Mike, Thanks, yes, that helped. I've been doing some more research into MVC and guess i originally misinterpreted it. I've now separated the model from the view and the controller is the host form. So what i have ended up with is: * A Generic Tree that raises events on change and can be serialized * A composite control set that takes an instance of the above Tree and observes it, keeping synchronized. This custom control also raises user events. * A Controller that handles all events from all controls, and manipulates the Generic Tree; cascading changes to any observing views. That seems to be a really nice way of doing things, and I'm really happy with it. I feel as though the penny has finally dropped for that particular way of thinking. Cheers :D Tris Question: Does the fact that the composite control also raises user events change its role in anyway? Or is that perfectly acceptable?
------------------------------- Carrier Bags - 21st Century Tumbleweed.