John Anderson wrote:
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.yes, they do have a controller, although its very rudimentary - its the dirty block mechanism. 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 screenSo I think what we're really debating about is how the "dirtying" works. Lets see if I've got you position correct. If everything goes according to what you say: 1) when changes come in, you want to flag a block dirty only if the changes affect the given block. Each block can do some pre-processing to determine which changes are relevant. 2) when the block is dirtied, the block is resynchronized during the onidle loop 3) its up to the block to have saved some sort of hint about what is actually affected during 1), so that when the synchronize happens, they know what to update on screen Advantages: blocks are only "dirtied" and resynchronized (i.e. synchronizeWidget() is called) only if the notifications caused a relevant change. Disadvantage: hints must be processed once when they come in as parameters from notification callbacks (in 1) above) to filter out the relevant hints, or transform the hints into block-specific hints. Then the filtered/transformed hints need to be processed again during 3), when the block has to look through the hints to see what specifically needs to be updated Here's what I'm suggesting: 1) when changes come in, they are unconditionally accumulated. Blocks are "dirty" if any notifications have come in for that block 2) when the "dirty blocks" are synchronized via synchronizeWidget(), the blocks decide if they need to actually rebuild themselves based on the hints that came in. Advantages: hints are processed in one place - synchronizeWidget(). further, the same hints, in the same format, are used across all blocks. No special code needs to be written to decide which blocks are "dirty" and which aren't. Disadvantages: blocks may be considered "dirty" even if synchronizeWidget() ends up doing nothing. don't want to accumulate your hints on my block because I'll never use them.That makes no sense, unless you really want to think of them as 'Alec's personal hints' - because its the same exact information, bit for bit, that you'd be processing in your table. I'd just pass them to you in synchronizeWidget, rather than inventing a new way for blocks to intervene in the block-dirtying process. I'm suggesting a general mechanism for all blocks rather than requiring each block to figure out how to defer the hints until the synchronize. In my mind, that is simpler, more general, and much easier to maintain. Alec 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? |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
