On 10/12/05, mental@...3... <mental@...3...> wrote:
Quoting Ben Fowler <ben.the.mole@...400...>:
In classic MVC, the View would be bound directly to the Model, with no layer in between.
... To me it seems to have the fatal drawback that the Model has a dependency on the View and must know how to drive each and every View that interested developers come up with.
No, it just means that the View would use callbacks or an Observer-ish interface to receive notifications from the Model. The Model need have no knowledge of the specific View class whatsoever.
1. I had actually decided that it was time to let others have the last word here, but just in case I had somehow got under your skin, let me repeat my initial comment, that if I am off charter, I apologise.
Some of this is wiki material, that is for sure.
I agree that "The Model need have no knowledge of the specific View class whatsoever", and this should be regarded as a valid correction to the excerpt you quoted.
2. Perhaps my comment was naive, but it is not altogether wrong; in an open source project (this is discussed towards the end of the Red Bean book) interfaces and the territory between components should be regarded as mobile and changed whenever necessary (meaning when the alternative is ugly or unmaintainable code or code that is bad match to the projects medium or long term goals). Just think what would be going through your mind if someone suggested that all the user interface should go though callbacks (see http://wiki.inkscape.org/cgi-bin/wiki.pl?Coding_Style for the phrase 'summarily shot').
I think, though I may be wrong, that someone would have to decide what goes into the group of callbacks available a "knowledge of View classes in general, or knowledge of a putative View base class", and probably someone will have had to design the architecture so that it was available when the list of callbacks required was originally made.
I quoted a URL above which has a take on how difficult it is for coders to do this in a timely fashion; and in any case this is a skill which is nearly non-existent on Sourceforge.
To come back (briefly) to my point: I was hoping that it would be possible to designate some files as being part of the Model, tag them with a line like
/* This file is part of the Inkscape MODEL */
for the benefit of grep, and perhaps re-arrange the code and/or the namespaces and/or the directory structure and/or the Makefiles, so that those files could be compiled and linked without GTK+ and without GDK.
(Obviously I would also like to tag other files as VIEW and CONTROLLER, but this is far less important, and from comments above, I guess not sustainable).
Also, is there (or should there be) an Inkscape API?
The View, of course, is aware of the Model class and manipulates it directly.
Yes