MVC v's Morphic for development
ned at bike-nomad.com
Sat Oct 13 17:18:50 UTC 2001
On Saturday 13 October 2001 04:03 am, Patrick Castle wrote:
> I know Morphic is the way of the future with Squeak and good to see really.
> However, when I've downloaded various tutorials on Morphic it is all very
> much direct manipulation and scripting. These are all fun, but not exactly
> where I want to be heading.
That's not Morphic, it just uses Morphic. You're talking about subsystems
(like EToys) that are built on top of Morphic.
> I know I'm new to this but it makes sense to me to work on the application
> away from the GUI and then attach the GUI later. I know this is an MVC way
> of developing things but I'd rather use Morphic (for a start there's a
> wider variety of Morphs). Do any Morphic tutorials take the more
> traditional approach of developing the application with the more
> traditional MVC approach or am I better off studying MVC first and then
> following or breaking the rules in Morphic later?
There is no reason you can't use a publish/subscribe system like MVC with
Morphic. Of course, the "C" in MVC is a bit redundant, as the Morphs deal
directly with user interaction. (so like most modern UI widgets, the VC are
combined into a single object).
There are no rules against notification in Morphic.
Don't get confused between MVC projects/worlds and the MVC pattern itself.
There are at least three event notification systems built into Squeak:
* the Pluggable* morphs (which are the Morphic version of UI widgets that
have MVC equivalents) talk to their model directly using configurable
* the classic addDependent: and update: (et al.) methods from MVC (protocols
"dependents access" and "updating" in Object)
* the when:send:to: and trigger: (et al.) methods, which are easier to use
than the above (protocol "events" in Object). I prefer these, because they're
finer grained and higher performance.
There are two directions for notification:
1.) When the model changes, you want to change the Morph.
a.) You can either notify the Morph indirectly that it's changed (using one
of the notification schemes above), or
b.) use the Morphic stepping protocol: each Morph can ask to have its step
method called periodically (and it can choose the period). The step method is
called from within the UI process loop. This step method can look at the
model, decide if a change in appearance is necessary, and call "self changed"
if it is. This is more "classic Morphic" than event notification, and avoids
certain problems with event notification (like update loops), though it is a
bit higher overhead.
2. When user interaction happens, you may want to send a message to the
model. There is pluggable event handling in Morphs that can do this easily:
m _ Morph new openInWorld.
m on: #mouseDown send: #inspect to: 'mouseDown'.
m on: #click send: #inspect to: 'click'.
m on: #startDrag send: #inspect to: 'startDrag'.
You can use the Morphic properties (sort of dynamic instance variables) to
add a reference to a model to any Morph, even those that don't have a "model"
m setProperty: #model toValue: someObject.
m valueOfProperty: #model
> As an addition to this, am I likely to have all my dreams come true if I
> buy "Squeak: Object-Oriented Design with Multimedia Applications" by Mark
> Guzdial? Will it be the Morphic guide I am looking for?
Have you seen this book online? I believe you can take a look at it somewhere
(sorry, don't have the URL). It gets into the details of Morphic (as well as
the Pluggable* and MVC UI elements) pretty well. I don't think it'll make you
a Morphic expert, though; you have to actually play with the system for that.
currently: Stanwood, WA
email: ned at bike-nomad.com
More information about the Squeak-dev