|
Blocks and widgets doen't really have a controller. But I don't really
care about that. If you want to make a controller we can do that. What I really care about is a performance issue. I want to be able to process the notifications for my table, ignore changes to items that aren't visible and ONLY keep a dirty bit if the change affects something on the screen. I don't want to accumulate your hints on my block because I'll never use them. It just makes things way more efficient if we can process notificaitons as we go instead of storing them to process later. Surely we can think of a way to do this that works with your MVC view of CPIA, right? John Alec Flett wrote: John Anderson wrote:I'd still vote for this hint accumulation to be block specific, e.g. Calendar only. Consider the case where you did some very large operation and didn't get back to the idle loop for a long time. Also, for many blocks, e.g. Table and Calendar most if not all the hint information doesn't need to be kept around until synchronization, it can be processed when the event is handled and never needs to be stored.I think that doing that would once again break the MVC paradigm in CPIA. It seems like you're saying that for some operations, the model should be talking directly to the view, and bypass the controller.. the notification mechanism is a pretty key part of the controller. The controller (in this case the block synchronizing code) needs to ensure that mutations to the model are propagated to the view in the order they happen. If the model (blocks) immediately updates the view (widgets) in some cases, but notifications are also coming in asynchronously via the synchronizeWidget() call, then things are more or less guaranteed to get out of sync. |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
