Troels Henriksen wrote:
"Knut Olav Bøhmer" bohmer@gmail.com writes:
Then the wind speed and direction changes, so the object is updated. Now I need to update the presentation to reflect the changes in the object.
I don't think you're supposed to do that. IIRC, output presentations should not be associated with objects that mutate a lot.
How can I update just that object?
Since presentations are output records, you could define a method on REPLAY-OUTPUT-RECORD and call REPLAY on the appropriate presentation object, but it's not exactly elegant.
This is actually a question of considerably interest to me. It sounds like Knut and I may have similar interests.
The CLIM UI model maps nicely onto conventional document-oriented applications. There's an artifact out there (I'm probably overly constraining things by calling it a document), and the user manipulates it with various commands, and the display updates to reflect the changed state of the artifact.
I have found it much more difficult to figure out how to take this UI model and map it onto process control applications, which are of primary interest to me. In such applications, there is an external process, operating asynchronously with the program, that sends (conceptually, at any rate) updates that should be reflected on the display, so that the user remains aware of the state of the process.
Such applications seem to map less cleanly onto the CLIM model, and *may* fit more nicely onto constraint-based UI frameworks like Garnet and whatever that cells thing is...
There's probably a way to create an observer process that will capture the state updates, update the various objects and cause them to be redisplayed, but I don't know of a way to do this that elegantly captures the behavior.
Speaking of which, I'm not big on the design patterns stuff --- is there a design pattern, analogous to model-view-controller, that captures what one does when writing a process control UI?
Best, R