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
data.
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.
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
