Controllers are the traffic cops of your application. They decide how to
react to events, they coordinate interaction with other controllers and
they define some of the overall characteristics of a view such as which
events it will generate and how it should respond to things like the close
button being pressed. For a general introduction to the idea of MVC and the
role of a controller, please see: en.wikipedia.org/wiki/Model-view-controller.
Monkeybars is not, strictly speaking, an
MVC framework. However the general idea of the seperations of concerns
that most people think of when you say ‘MVC’ is applicable.
The controller defines the model and view classes it is associated with.
Most controllers will declare a view and a model that will be instantiated
along with the controller and whose life cycle is managed by the
controller. It is not required to declare a view or model but a controller
is of questionable usefulness without it.
The controller is where you define any events you are interested in
handling (see add_listener) as well as
two special events, the pressing of the “close” button of the window (see
close_action), and the updating of the MVC tuple (see update_method). Handlers are methods named according to a certain
convention that are the recipient of events. Handlers are named <component_event>. No
events are actually generated and sent to the controller unless a listener
has been added for that component, however, component-specific handlers
will automatically add a listener for that component when the class is
instantiated. Therefore a method named ok_button_action_performed would
be the equivalent of
add_listener :type => :action, :components => ["ok_button"]
These automatic listener registrations work for any component that can be
resolved directly in your view. In the above example, the view could
contain a component named ok_button, okButton or even OkButton and the
listener would be added correctly. If you have a nested component such as
text_field.document then you will need to use an explicit add_listener registration.
Handler methods can optionally take one parameter which is the event
generated by Swing. This would look like
def some_component_event_name(swing_event)
Automatic listeners can also be decorated with a trailing ! to indicate
that the update_view
method should automatically be run on completion of the callback being run
from a Swing event. In the previous example
def some_component_event_name!
end
is the equivalent of
def some_component_event_name
update_view
end
While an event handler is running, the Swing Event Dispatch Thread (usually
called the EDT) is blocked and as such, no repaint events will occur and no
new events will be proccessed. If you have a process that is long running,
but you don’t want to make asynchronous by spawning a new thread, you can
use the repaint_while method which takes a block to execute while still
allowing Swing to process graphical events (but not new interaction events
like mouse clicking or typing).
def button_action_performed
repaint_while do
sleep(20) # the gui is still responsive while we're in here sleeping
end
model.text = "done sleeping!"
update_view
end
Example of a controller, this assumes the existance of a Ruby class named
MyModel that has an attribute named user_name that is mapped to a field on
a subclass of Monkeybars::View named MyView that
has a button named “ok_button” and a text field called user_name
require 'monkeybars'
class MyController < Monkeybars::Controller
set_view :MyView
set_model :MyModel
close_action :exit
def ok_button_mouse_released
puts "The user's name is: #{view_state.model.user_name}"
end
end
It is important that you do not implement your own initialize and update
methods, this will interfere with the operation of the Controller class (or if you do be sure to call
super as the first line).
![[+]](../images/find.png "show/hide quicksearch")