I have used binding mechanisms in the Flex framework, which act in a similar way. The model object dispatches events which the view listens to and updates its own representation. In Flex the model object is often an "ArrayCollection," in this example, "Donuts." In Flex the view would often be some kind of "List" object, in this example, "DonutCollectionView."
The Donut aspect of this example is the contrived bit. It's just a generic list. Donut could just be any Object that maps to some kind of HTML representation. DonutCollectionView could just be a CollectionView, that passes along that representation to a HTML list.
The plumbing in this example is something I don't really want to write if I am using a framework. If I had to write it, I wouldn't write it like this. Am I misunderstanding something?
You're absolutely right that it's vastly overcomplicated for the task that needs to be accomplished here.
In MVC style, a donut model shouldn't know anything about its HTML representation, and there's a 1-* relationship between models and views on those models.
For example, you might have one view of a donut that shows its picture, and another view that shows its ingredients. When displaying a collection, you do want the collection to manage whether to display these things using an HTML list or table or lightbox picture browser or whatever.
But each donut should be a model that knows what it is to be a donut but not how donuts are displayed, each donut view to know how to display a donut, and the collection view knows how to organize what each individual donut view renders.
The other reason you need a view for each donut is that you might want interactivity. For example, if you want a zoom control for a donut picture, that logic would go in the donut view. The donut collection view knows about scrolling, paging, whatever but not zooming. The donut view knows about zooming. And donuts know about sugar and flour and chocolate and sprinkles.
In Flex, this is managed by a 2-part view consisting of the collection view (List) and the item view (ItemRenderer). When creating the List you pass it its data provider (oft. ArrayCollection) and its ItemRenderer.
Perhaps this example could benefit from a similar separation.
