Viewing in Morphic (was: Re: The Weekly Juan #4: "Smalltalk, Direct
Manipulation and End User Programming")
Andreas Raab
andreas.raab at gmx.de
Tue Nov 14 04:58:59 UTC 2006
[Changing the subject since this part seems to be mostly about viewing]
Juan Vuletich wrote:
> For example, I don't agree at all with "Morphic is a wonderful
> architecture as far as direct manipulation is involved but it's a
> terrible architecture to build reusable systems. Morphic simply doesn't
> have any abstractions and that makes it very hard to build re-usable and
> flexible components."
Which part do you disagree with? That it's a wonderful architecture for
direct manipulation? That it's a terrible architecture for building
reusable systems? That it doesn't have abstractions?
> "Because MVC is a "viewing architecture"... Tweak ... provides a viewing
> architecture similar to MVC." I don't agree with this either. In Tweak,
> a player knows its primary costume. In MVC, one of the key ideas is that
> a view knows its model, but a mode knows nothing about the views on it.
> I believe the viewing architecture to be quite different.
You're actually only looking at a part of viewing in Tweak - namely that
of graphical models which indeed know their primary views. This is not
generally true - all that is required for viewing in Tweak is that an
object #signal: the occurrence of an event that a view can observe
(which is very much like MVC's change/update mechanism except that it
executes asynchronously by default and is supported and used all the way
top to bottom in Tweak). And many Tweak objects act as views on numerous
other objects (indeed, part of the implementation of Tweak depends on
objects "viewing themselves").
For *grapical* models (players) it is indeed true that they know their
primary view (the costume) but this is mostly to optimize management of
some state (which is held exclusively in the costume). I actually
debated this for quite a while initially and went for it due to the
space savings, but I may (have to) reconsider it in the context of
Croquet simply because there may be no notion of a "primary" view for a
(replicated) model under a (non-replicated) viewing environment.
> WRT method annotations for event handlers, it seems as if the receiver
> of the message for some object was always the object triggering the
> event. Usually it is not. It could be an owning morph, or the model(if
> the event is from the gui), or the view (if the event is from the
> model). This is also related to the model not knowing about the view in
> MVC.
I presume that by "the receiver of the message for some object was
always the object triggering the event" you mean that the signaler and
the handler of the event are the same (if not, please clarify). If
that's what you mean then you are right, usually they are not the same.
This is why you have <on: eventName in: signaler> annotations (and the
common <on: eventName> is effectively shorthand for <on: eventName in:
self>).
Part of the goal for these annotation is that for many applications it's
nice to be able to "centralize control" in a single place. In other
words, I often prefer a style that uses:
onFireInMyButton
"MyButton has been fired. Carry out some action."
<on: fire in: myButton>
target doButtonAction.
to one that uses, e.g.,
button on: #mouseDown send: #doButtonAction to: target.
The latter version certainly has its uses but I find the former much
more accessible in terms of looking at a class and how it defines the
relationship between the entities it deals with (in particular in a
Tweak browser where event methods have icons so that you can immediately
see which of them are event responses).
Another major advantage is that when I need to add/change/remove one of
these events I don't have to poke around all over the places to find
where the button is initialized and change other people's code - I can
write a clean new method, state the relationship right there and then
and get the result. Plus, renaming and changing events doesn't require
me to execute manual code (the system takes care of transferring the
triggers), nor does it require me to manually change event relationship
if the button ever changes (again, Tweak transfers the event responses
automatically when you change a field). [there are numerous other
advantages that I won't list here because this is getting excessive already]
And just for completeness, there is of course a way to do the
programmatic equivalent of the latter via:
target startScript: #doButtonAction when: {button. #fire}.
So the bottom line is, you're right, often the signaler and the handler
of an event aren't the same and Tweak supports that common use case too.
And I would claim that it supports this use case better than Morphic
ever could.
> ScorePlayerMorph and EnvelopeEditorMorph are good examples of views on a
> model, in the classic MVC idea of the view knowing about the model, and
> the model not knowing about the view. I don't see the need for a "theory
> of viewing". It is enough with separating the view and model
> responsibilities, and triggering events, just as in MVC.
Interesting. For two reasons really. First, I wouldn't even consider
these to be "morphs" but rather what I would call "application shells".
By which I mean there is nothing intrinsically graphical about the two,
nor even anything interactive - neither of the two chosen examples
implements drawing or event handling (mouse or keyboard) which given the
definition of a Morph as:
[Morph classComment]
A Morph (from the Greek "shape" or "form") is an interactive graphical
object.
strikes me as non-Morphic as it gets (given that the two defining
properties of being graphical and being interactive aren't met).
But besides, you do realize that both of the examples you are mentioning
are polling in their step methods for any changes in the model, right? I
think one could consider this a form of viewing but I don't consider
step-polling to be an actual viewing architecture because it gets very
excessive pretty quickly. Case in point: PianoRollScoreMorph. It polls,
too, and when it detects a change in its model it recreates all these
morphs from scratch (besides the criticism implied here it's actually
quite impressive how well this works). However, given current Morphic
usages step-polling seems to be the prevalent method of determining
changes in Morphic.
So, I guess I have to correct myself, Morphic does indeed support
viewing via step-polling (but I still wouldn't call that a viewing
architecture ;-)
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|