From: Brett L. <wak...@ea...> - 2005-12-10 02:44:25
|
>> So, as you can see, the fundamental question that you're >> trying to answer for ORWindow, "When do I draw things?" is >> answered with, "Whenever someone calls your paint() method." >No, the fundamental question actually was: *what* to draw when it is time >for drawing. >How to tell a field in these windows that its *value* has changed. >OK, needed for any good solution (mine or yours) is that we give >each UI field a reference to a model that holds the value to be displayed. >We seem to agree on that, and that is the first thing I'm going to add now. >Once that is done I think we'll be a lot more flexible. >Where we still differ is on the question as to whether a UI field on a >repaint() >should *always* call its model for the current value (your way), >or would have that value already received before through observance >of its model (my way). But that is not a big difference anymore, >the details will be hidden in a few specialized classes. Ok, I see what you're saying. I don't think our app is so complex that we really need to worry about delaying updates to the UI. I think we're fine with 'when the UI repaints, it obtains the values from it's copy of the model.' I think using Observers is over-engineering the solution where the existing painting system works well enough and doesn't require building a whole new subsystem. >Good discussion this was! >At least it has sharpened *my* thoughts a lot. Great! I agree, it's good to hammer out these sort of details. ---Brett. |