About



Thanks for checking out Monkeybars. This is a library that enables you to make use of Swing from JRuby. Monkeybars aims to allow you to continue using the GUI editing tools you are used to but makes it easy to write all your application logic in pure Ruby. In fact, with most editors you’ll never even have to look at the Java.

Philosophy


Origins




Monkeybars was created from a pretty specific need. My company, Happy Camper Studios was working on a large Swing application and we wanted to be able to easily write all the logic in Ruby via JRuby. Our initial attempts laid the groundwork for what was to become Monkeybars. Because of our needs, Monkeybars has an emphasis on using normal Swing development tools (we were using Netbeans 6) and especially the ability to sit down with a client and use a visual designer to create the Swing layouts. To this end, Monkeybars is designed to reach in and integrate itself with a Java class without any special consideration on the Java side. This means Monkeybars should work with Java code emitted from any Swing form designer, we don’t parse the code directly so there is no issue with code formatting or code conventions used inside the class.


So, what do we mean by “easily”? Well, I’ve got a pretty low tolerance for pain in my code so ideally everything gets reduced down to a one liner. Want to set up mouse event listeners on all elements in your form?


add_listener :type => :mouse


Or how about declaring that only the components okButton and cancelButton should get mouse events?


add_listener :type => :mouse, :components => “okButton”, “cancelButton”


How about sending some long-running task off to its own thread without freezing the GUI until it is done?


repaint_while { # call some long running method }

Still not convinced? Go so more code samples on the examples page.

Testing

A second important consideration for us was testability. Our early attempts to create a Ruby interface to Swing left us with brittle, difficult to test code. Therefore in Monkeybars we implemented a stark separation between controller and view. All* communication between the two is accomplished via a model which is just a plain Ruby class. This keeps your controllers much more testable. The views also are typically smaller and much easier to test, only being concerned with their methods to convert data from and back into the model.


* I say all but in reality there is direct communication between the controller and the view, it’s just behind the scenes so you don’t have to think of it in terms of direct communication.