[Dev] Problem with collection notifications
john at osafoundation.org
Mon Sep 26 12:24:56 PDT 2005
Alec Flett wrote:
> 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.
If it's part of the view it can't be persisted, which won't work
> 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.
Blocks should always be model, widgets should always be view.
> 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.
Window size is model data wich we store in block. Selection is a little
tricky, currently it's part of the block, but I'm moving it out to the
collection -- actually it's really going to be part of the index on the
>> 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?
When the data changes we need to update the widget, e.g. view, not 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.
If the selection isn't part of the block or the collection it won't be
persisted, which won't work. In relality the selection is stored in both
the widget and a block or collection. We need to keep they in sync. If
the widget changes its selection we need to reflect it in a persistant
model. If something outside the platform changes the persistent model we
need to have a way to sychronize the widgets's idea of the selection.
>>> 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..)
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dev