5. Building a UI for Count

• Let's build a UI (HIC) for Count
• Assumes that the Count exists: http://www.cc.gatech.edu/fac/mark.guzdial/squeak/SrcFor2390/Counts.st
• Requirements
• It works for all subclasses of Count
• Involves minimal changes to the PDC
• Separates model (PDC) from view (HIC)
• Changing one doesn't impact the other
• A general and reusable framework that we can use in other situations
• First Pass: Direct calls
• http://guzdial.cc.gatech.edu/st/countUI1.cs
• CountView puts up buttons and a text display of the value
• The CountView knows the Count
• We modify Count to tell the CountView to change the text display when the value changes
• The Count knows the CountView
• Count UI Version 1
• 
• CountView Drawing
• CountView methodsFor: 'drawing' stamp: 'mjg 4/8/98 13:00'
• draw
• | background myPen|
• background := (Form extent: 400@300) fillWhite.
• background display.
• "Display buttons"
• myPen := Pen new.
• myPen black.
• myPen up.
• myPen goto: 0@100; turn: 90; down; go: 400. "Horizontal line for buttons"
• myPen place: 150@0; turn: 90; go: 100. "Vertical lines to separate"
• myPen place: 300@0; go: 100.
• 'Increment' displayAt: 20@50.
• 'Decrement' displayAt: 170@50.
• 'Reset' displayAt: 320@50.
• CountView Drawing of the Text Display
• CountView methodsFor: 'drawing' stamp: 'mjg 4/8/98 13:01'
• drawValue: myValue
• ' ' displayAt: 170@250. "Clear out the old one"
• myValue printString displayAt: 170@250.
• How Count tells CountView to Update
• Count methodsFor: 'accessing' stamp: 'mjg 4/8/98 12:59'
• value: aValue
• "Set my value to aValue. "
• value := aValue.
• myDisplay isNil ifFalse: [myDisplay drawValue: value.].
• "Have to watch out for the value being set before the UI is defined"
• How buttons get processed
• CountView methodsFor: 'eventWatching' stamp: 'mjg 4/8/98 12:53'
• buttonProcessing
• "If right (blue) button pressed, stop processing.
• Otherwise, wait for a left (red) button.
• If it's in a button, send the right message to the count."
• | startLoc |
• [Sensor blueButtonPressed] whileFalse:
• [(Sensor redButtonPressed)
• ifTrue: [startLoc := Sensor mousePoint. "This gives us the cursor point"
• ((0@0 corner: 150@100) containsPoint: startLoc)
• ifTrue: [myCount perform: #increment].
• ((150@0 corner: 300@100) containsPoint: startLoc)
• ifTrue: [myCount perform: #decrement].
• ((300@0 corner: 400@100) containsPoint: startLoc)
• ifTrue: [myCount perform: #reset].
• ]]
• Running Version 1
• demo
• | aC aCV |
• aC := IntegerCount new.
• aCV := CountView new.
• aC myDisplay: aCV.
• aCV initialize: aC.
• Report Card on Version 1
• Does work for all subclasses of Count
• Involved serious changes to the PDC
• New instance variable, must explicitly track view, must update view
• Whose responsibility is that, anyway?
• View is highly Count-dependent, so doesn't separate model and view
• Not at all general and reusable
• How could we get better?
• Pull out the buttons
• Make them responsible for their own model, their own drawing
• The view will only them as "pieces"
• Second Pass: Generalized buttons
• http://guzdial.cc.gatech.edu/st/countUI2.cs
• CountView keeps track of pieces
• Asks them to draw themselves
• Ask them if they can process a given mouseclick
• CountView no longer needs to know the model, but buttons do -- generically
• MyButton knows its name, rectangle (rect), and model
• It knows the Count, but not as a Count. Could be anything
• Subclass MyButton to send different messages to the model on mouseclick
• Count UI Version 2
• 
• CountView2's Drawing
• CountView methodsFor: 'drawing' stamp: 'mjg 4/8/98 15:30'
• draw
• | background|
• background _ (Form extent: 400@300) fillWhite.
• background display.
• "Display pieces"
• pieces do: [:each | each draw].
• MyButton's Drawing
• draw
• | myPen |
• myPen := Pen new.
• myPen place: (rect origin).
• myPen black.
• myPen down.
• myPen turn: 90; goto: (rect origin x)@(rect corner y).
• myPen turn: 90; goto: (rect corner).
• myPen turn: 90; goto: (rect corner x)@(rect origin y).
• myPen north; goto: (rect origin).
• name displayAt: (rect origin) + (20@20)
• CountView2's Event Processing
• startProcessing
• | startLoc |
• self draw. "Draw myself, and all of my internal objects"
• "If right (blue) button pressed, stop processing.
• Otherwise, wait for a left (red) button.
• If it's in an internal piece, let them process."
• [Sensor blueButtonPressed] whileFalse:
• [(Sensor redButtonPressed)
• ifTrue: [startLoc := Sensor mousePoint. "This gives us the cursor point"
• pieces do: [:each | each canProcess: startLoc].
• ]]
• MyButton's Event Processing
• canProcess: clickPoint
• (rect containsPoint: clickPoint) ifFalse: [^false]
• ifTrue:
• [self mouseClick.
• ^true].
• mouseClick "Default behavior"
• model mouseClick.
• Individual Buttons
• MyButton subclass: #DecrementButton
• instanceVariableNames: ''
• classVariableNames: ''
• poolDictionaries: ''
• category: 'Count-IntegratedUI'
• DecrementButton methodsFor: 'event processing' stamp: 'mjg 4/8/98 13:21'
• mouseClick
• model decrement.
• Running Version 2
• demo2
• | aC aCV iButton dButton rButton |
• aC := IntegerCount new.
• aCV := CountView new initialize.
• iButton := IncrementButton new
• initialize: 'increment' for: aC in: (0@0 corner: 150@100).
• dButton := DecrementButton new
• initialize: 'decrement' for: aC in: (150@0 corner: 300@100).
• rButton := ResetButton new
• initialize: 'reset' for: aC in: (300@0 corner: 400@100).
• aCV addPiece: iButton. aCV addPiece: dButton. aCV addPiece: rButton.
• aC myDisplay: aCV.
• aCV startProcessing.
• Report Card on Version 2
• Still works for all subclasses
• Same changes to the PDC
• But the View is no longer Count-dependent
• Could change number or type of buttons, and CountView wouldn't change
• Model (Count) still is view dependent, though -- it knows CountView still
• More general and reusable
• Task-specific buttons are just small subclasses of MyButton
• How could we get better?
• Only reason we subclass MyButton is to specialize mouseClick
• What if we added an instance variable action?
• Mouseclick could then be generic
• mouseClick
• model perform: action
• This is called being "pluggable"
• Third Pass: Generalized text area
• http://guzdial.cc.gatech.edu/st/countUI3.cs
• TextArea knows its model, the "asking" message, and the location for the text area
• Rather than the Count knowing the textArea, we'll use changed/update
• How does the View find out that it must update?
• A View gets created on a specific model
• When the Model changes (self changed: parameter>), it announces that the change to all of its Views
• The view gets told to update:
• If the View cares about the aspect that has changed, it asks for the data.
• Picture of MVC Update Process
• 
• Important Observations
• At no time does the Model directly send info to the View.
• It only responds to a request
• In fact, the Model has no idea what Views care about which of its aspects at all!
• It only has a list of dependents that get alerted when there is a change.
• TextArea
• initializeFor: aModel asking: aMessage at: aLocation
• model := aModel.
• message := aMessage.
• location := aLocation.
• model addDependent: self. "Needed for update/change mechanism"
• canProcess: something
• ^false.
• draw
• ' ' displayAt: location. "Clear out the old one"
• (model perform: message) printString displayAt: location
• update: anything
• self draw.
• Count now just announces changes
• value: aValue
• "Set my value to aValue. "
• value := aValue.
• self changed: #value.
• Running Version 3
• demo3
• | aC aCV iButton dButton rButton aTA|
• aC := IntegerCount new.
• aCV := CountView new initialize.
• iButton := IncrementButton new
• initialize: 'increment' for: aC in: (0@0 corner: 150@100).
• dButton := DecrementButton new
• initialize: 'decrement' for: aC in: (150@0 corner: 300@100).
• rButton := ResetButton new
• initialize: 'reset' for: aC in: (300@0 corner: 400@100).
• aCV addPiece: iButton. aCV addPiece: dButton. aCV addPiece: rButton.
• aTA := TextArea new initializeFor: aC asking: #value at: 170@250.
• aCV addPiece: aTA.
• "aC myDisplay: aCV."
• aCV startProcessing.
• Report Card on Version 3
• Pretty generic
• It would be nice if this would work as-is within a window :-)
• How would we resize any of this? All locations are hard-code right now
• Problem: Processing events is buried within the View
• What if we want something different in our view, like drag-and-drop or selectable text?