I must be missing something. I've read a bunch of documents on morphs, including why they are "way cool". I've played around with them a little bit.
It seems to me the argument for separating the model from the view/controller is a good one. And it seems to me the "cool" thing about morphs is that they don't separate these things.
All the buzz at least suggests that morphs represent some kind of mind-shift from the usual way of doing things. My mind seems not to have shifted! Could anyone help me out on this one?
Do you agree that morphs include both the GUI and the model? Or are morphs intended to be a more capable GUI layer that will still operate in tandem with underlying, non-graphical model classes? If not, why is combining model and GUI a good thing?
Regardless of the first point, what is or are the core innovations of morphs?
On Tuesday 27 March 2001 12:28, Ross Boylan wrote:
It seems to me the argument for separating the model from the view/controller is a good one. And it seems to me the "cool" thing about morphs is that they don't separate these things.
The appropriateness of any design pattern (in this case, MVC (Observer)) has to be determined in context. One of the useful things that the so-called "Design Patterns" movement did was to introduce a convention for discussing the appropriateness of such patterns.
These are engineering decisions, not moral judgements. There is no absolute moral superiority of model/view separation. Similarly, there is no moral superiority of "object-orientedness".
All the buzz at least suggests that morphs represent some kind of mind-shift from the usual way of doing things. My mind seems not to have shifted! Could anyone help me out on this one?
Morphs are indeed different, but not necessarily with respect to the model/view separation. There is, in fact, a MorphicModel hierarchy that allows for MVC designs using Morphic GUI elements. The browsers, etc. all are designed this way (look at the Pluggable*Morph classes).
Do you agree that morphs include both the GUI and the model?
They can, if you want them to.
Or are morphs intended to be a more capable GUI layer that will still operate in tandem with underlying, non-graphical model classes? If not, why is combining model and GUI a good thing?
Regardless of the first point, what is or are the core innovations of morphs?
(I hit control-Enter accidentally before I was finished)...
On Tuesday 27 March 2001 12:28, Ross Boylan wrote:
Or are morphs intended to be a more capable GUI layer that will still operate in tandem with underlying, non-graphical model classes?
They can be if you want them to be.
If not, why is combining model and GUI a good thing?
More like "when is it a good thing": * when you don't have multiple views on the same model * when the end user is constructing Morphs and behaviors on the fly * when you don't need the added complexity that MVC brings to the design
Regardless of the first point, what is or are the core innovations of morphs?
Lots of reading out there:
http://dmoz.org/Computers/Programming/GUI/Morphic/ http://www.sun.com/research/self/papers/self4.0UserInterface.html http://minnow.cc.gatech.edu:8080/squeak/uploads/self-4.0-ui-framework.pdf (if Minnow ever gets back up)
squeak-dev@lists.squeakfoundation.org