Subject: Re: some more info on multi-view list crash
From: Mike Nordell (tamlin@algonet.se)
Date: Fri Nov 24 2000 - 23:51:14 CST
Martin Sevior wrote:
> I think what is happenning is that that fl_AutoNum is trying to start two
> lists based on the same shd and id number. I think this can be fixed by
> checking to see if there is already a list defined in the vector of lists
> in pd_Document.
That would be a fix, but I think it's only a fix for the symptom, not the
problem. If feasible I'd really like to work on a fix for the problem
instead of the symptom.
So, here's my quick analysis and opinions on this:
When telling the AW to create a new list by clicking a toolbar button, this
order goes to the View, and then the View is responsible for carrying out
that order. That's one error. A View should only be what it's name implies.
It should never be able to modify it's document in a "clean" world. But
since the view in this case doubles as controller, we regrettably have to
deal with it. But, we can enforce that a view may never request a document
change by any other means than a *direct* user interaction (as opposed to an
indirect interaction, e.g. a notification event).
Another error is that there are circular dependencies between e.g.
PD_Document and fl_Blocklayout (with a few other classes also entangled in
this).
Yet another error is that (apparently) some classes are allowed to modify
the document when it gets notification events regarding that same document.
Yet again, circular dependencies. There should be only one entity at the
time allowed to modify the document. Currently any number of notified
enities can change the document in the middle of a notified update. That's
begging for trouble. The current situation allows the view to tell
fl_BlockLayout to start a new list. That one in turn tells the document to
changeStruxFmt which calls the piece table which calls the document telling
it to notify the documents listeners. One of those listeners is (indirectly)
again calling fl_BlockLayout that indirectly again tells the document to
notify it's listeners of an update...
I hope I'm getting though here.
So, what are my ideas about this?
1. Disallow the pt_PieceTable to generate notifications (to the document).
Since it's the document itself that initiates these changes it's itself
perfectly capable of notifying listeners when an update has occured. This
would remove one source of circularity.
2. Since View doubles as controller in this case, require that it only
requests document modification from the document itself. The controller part
of the view if perfectly capable of telling the document what insertion
point or selected range(s) it currently has (if any). If we currently don't
have a data type for selections (Range) we'll have to create a (composable)
such.
3. Make the document class' interface complete. For the problem at hand it's
the PD_Document that should have the method StartList, and that one should
only notify it's listeners (conceptually views) when that update operation
is complete.
Did it make any sense? Comments?
/Mike - please don't cc
This archive was generated by hypermail 2b25 : Fri Nov 24 2000 - 23:50:39 CST