Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Sp01 Final Exam Review: Displaying Alarm Status
See Final Exam Review - Sp2001
Comments? Answers? Criticisms?
I am going to take a stab at this with my waning knowledge of this info. To implement the the View/Model communication you have to establish dependencies between you're underlying model and the view. To implement this you use MODEL addDependencies: VIEW. Also add code within your model that calls change: which will send whatever symbol it's given to a dependent class, in this case the view.
a) Whenever the change method is called in the model the update: method in the view is called behind the scenes. The view has its own update method that defines what kind of changes need to take place.
b) Some kind of string defining what kind of alarm it is can be passed in as the input to the change: method. The update method in the view can check this value and call methods upon itself accordingly.
This solution is based off of the solution given by doug to the previous problem.
AlarmStatusView will have a vicinity that it's a view on. From this vicinity you can get at the vicinity's sub-vicinities (recursively, all the way down). Every time an alarm is triggered it sends a self changed: (self class name) message, and the vicinity will catch this them poll the alarms of that type to see which one's been triggered. Once the vicinity knows which alarm has been triggered it sends itself a self changed: message with the triggered alarm as the parameter. Then the parent vicinities (as well as any views) can respond accordingly. So the view knows about the alarm because it can just ask the vicinity it's a view on for which alarm is triggered, and it knows which vicinity the alarm is triggered in because it's a view on the vicinity (or if it's a sub-vicinity then it just recursively goes down until it finds the vicinity that has the triggered alarm) Bryan Kennedy
Link to this Page