Friday, 1 May 2009

View update thyself

The more I work with rich internet applications, the more I am becoming focused on ensuring that the view updates itself through data binding. Two recent issues have brought this thinking to the fore again. One relates to how we think about the view and its updating and the other is the way that user interface controls are implemented.

With respect to the we think about the view and its updating, there are multiple alternatives but the two that I am seeing most frequently are “how can a responder update a view after an asynchronous call to the server ?” and “what data reflects what the current status of the view?” The first of these approaches tends towards an attitude of pushing data into the view while the second sees the view responding to changes in the underlying presentation data model.

When I started my current project, I reread the patterns described by Martin Fowler (2006). With the patterns he describes, I lean heavily toward the supervising controller approach in my implementation of Flex applications. as a consequence, I don't talk about "how the responder updates the view?" but rather about “what data in the presentation model reflects the required changes in the view?” My views are written in MXML and extend (inherit) a base supervisor (ActionsScript). I endeavour to make the view (MXML) use data binding to retrieve changes in state and function calls to the base supervisor to handle user gestures. The direction of communication is always to the next level in the architecture so even the base supervisor doesn't expect to receive function calls from things that it calls or initiates. It uses commands or presentation model objects or domain objects to achieve the changes that will be reflected in the view.

The systems that I have worked on so far, haven't involved visual objects that move on the view (i.e. virtual worlds but a system that I am looking at may require such changes). We do have data grid columns and other visual components conditionally appearing and / or changing visual state. What we have done is define a data model that can be bound to that reflects the way that we want the visual components to behave. The binding utilities allow the higher level objects to recognise changes in the lower level objects without the lower level objects needing to know about the objects that are making use of them.

Well almost!!!

My most recent effort has been to implement a control that allows selection of branches of a tree and the multiple selection of entries in a Combobox. The difficulty is the assumptions behind the way that the UI controls are implemented.

For the tree control, I started with a data model that managed the selection of nodes in the tree and the retaining of state of the selected nodes. I then extended the the tree control so that it reflected the changes from the underlying data structure. My control and supporting data structure still has a long way to go before I would call it a reusable control but what it does prove is that a user interface control can be separated from the data that it uses. The remainder of the code doesn't have to ask the UI for what is selected. That is done by enquiring of the data.

In preparing to write my version, I looked at other examples that were available. I found them complex and difficult to adapt to our specific needs. What was more frustrating is that I found the Flex Combobox difficult to adapt. Not only does the Combobox attempt to control what is selected and how the selection is made, it makes assumptions about the nature of the drop down. My current implementation of the tree selection control doesn't use the Combobox control simply because it is difficult to control when the Combobox rolls the drop down up.

For a single selection from a tree, we had already had to change the way that it reopened the drop down because it would reposition to the wrong object. With the more complex selection strategy of the new control, trying to overcome the roll up and repositioning problems in the time available were just simply inadequate so we choose a path that would give us an implementation that almost works as we want.

The second UI component is one that allows the user to select multiple entries from the Combobox drop down. Here we were fortunate and found what seemed to be a working control. The only problem is that you give your data to the Combobox and at some point, you have to ask the Combobox what has been selected. Yes, it fires the change event so that could be used as a way of monitoring what has been selected but what you end up with is a duplication of effort. The control and your own data model track what has been selected.

At this point, I have made some adaptations to the control but I personally don't like the way that it behaves. I see the way these controls working as the control is given a reference to your data and then spits out at some point the selections or changes.

With a controls like these two, the user may select a number of items and then through a button request some processing. If you are using the change event or some other event to track changes then you land up duplicating a process that the control is already doing. Why no use data binding to an underlying data structure that the programmer can access directly to determine what has been selected.


Fowler, M. (2006, 18 July). GUI Architectures.   Retrieved 9 November, 2008, from

Fowler, M. (2006, 19 June). Supervising controller.   Retrieved 9 November, 2008, from

No comments: