Re: [Dev] Problem with collection notifications

[Alec Flett]

John Anderson wrote: Actually this isn't a CPIA issue, it's a platform issue. Consider the case when a window changes size. The platform notifies us of the change and we have to update the model, but we don't need to also change the platform widget, its already up to date. I would argue in that case that size is part of the view, not the model. Perhaps that is true of selection, really. Perhaps what we're looking at is that there are really 2 layers of MVC going on: 1) the collection is a model, the blocks are the view - when you update an item in the collection, the blocks should change to reflect the item. 2) the blocks are the model, the widgets are the view - when a block changes, the widgets must be updated. The problem is that sometimes the blocks are the view, sometimes the model. Currently the blocks have a pointer to the collection, which allows for updates to the "collection" model to be reflected up through the blocks all the way up to the widgets. So something like selection or sizing is weird: I mean who really owns this? It seems like selection and size are really part of the state of the view.. but what view? the blocks or the widgets? We store it in the blocks because we can persist it, but I really wonder if that's the right way to do this. This also means that we can go to the block and ask the block what the selection is - but really we have to do some work to make sure that the block selection stays in sync with the widget selection. The main thing to keep straight is that event driven platform frameworks keep the widgets up to date and all we need to do is reflect the change in the model. The completely different situation occurs when the data changes and for some reason the platform can't notice it. In that case we need to update the model and synchronize the widget to the new value. see, this is what irks me: "when the data changes...we need to update the model and..." - shouldn't the data BE the model? So maybe the question is: is the block the proper location to be storing the selection? Or perhaps, when you a ask a block for selection, it should be asking the widget what part of the view is selected (i.e. what row of a table) and then use that to determine what part of the model to return. Alec The problem is that we're trying to do BOTH: update the view and the model manually, and then wishing the controller wasn't getting involved. The reason for this is that we don't have complete control of our widgets: when a user clicks the mouse, the widget wants to update itself whether or not the model has actually changed. This is the one thing that always seems to be vaguely defined in the MVC implementations I've worked with, including CPIA: proper downstream (view -> model - maybe that's upstream? anyway..) communication. My suggestion would be for the view (i.e. the widgets) to maintain some sort of state about the fact that its changing an attribute (selection) and then ignore notifications on selection. I don't think that collection notifications should have to shoulder this burden because its really proprietary to CPIA's design. Yes, I\d like to ignore the notification. The problem is that I can't, because some of the notificaitons are asynchronous. Alec

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev