Ever wish you could utilize Ruby from your Java based web applications?

Waffle, a Java based Web Framework, now provides built in support for JRuby. This will allow you to easily write your Controllers in Ruby. The integration is simple and straightforward, taking advantage of functionality Waffle provides (without being a Rails clone).

A key feature of Waffle has always been its pluggable architecture. From the beginning we believed that the default behavior defined by the Waffle team might not be suitable for every situation. Therefor Waffle was built following an Interface driven approach. Practically all of Waffle's built-in functionality can easily be extended or replaced. This design made integrating JRuby support quite easy. The next 3 steps give a brief overview of how to integrate JRuby support into your Waffle based applications.

Step 1 - configure Waffle to be "Ruby Aware"

Waffle avoids XML like the plague but we still need to have a web.xml for our applications. This web.xml is where we can take advantage of Waffle's pluggability. The following three context-param nodes need to be added to your applications web.xml. This alerts Waffle that a few of its foundational components should be replaced with alternate implementations.

<context-param>
  <param-name>org.codehaus.waffle.context.ContextContainerFactory</param-name>
  <param-value>org.codehaus.waffle.context.pico.RubyAwarePicoContextContainerFactory</param-value>
</context-param>
<context-param>
  <param-name>org.codehaus.waffle.bind.DataBinder</param-name>
  <param-value>org.codehaus.waffle.bind.RubyDataBinder</param-value>
</context-param>
<context-param>
  <param-name>org.codehaus.waffle.controller.ControllerDefinitionFactory</param-name>
  <param-value>org.codehaus.waffle.controller.RubyControllerDefinitionFactory</param-value>
</context-param>

Step 2 - Your application's Registrar should extended AbstractRubyAwareRegistrar. This exposes a new registration method to use within your Registrar ... registerRubyScript(String key, String className). See the example below:

public class MyRegistrar extends AbstractRubyAwareRegistrar {

  public MyRegistrar(Registrar delegate) {
    super(delegate);
  }
    
  @Override
  public void application() {
    registerRubyScript("foobar", "FooBar");
  }
  ...
}

In this example the Ruby class named 'FooBar' will be exposed as a Controller under the name 'foobar' (e.g. http://localhost:8080/jruby/foobar.waffle).

Step 3 - Write your Ruby Controller class. Notice in the following example that your class does not need to extend or include anything.

class FooBar

  def index # This is the default action
    "<h1>Hello World</h1>"
  end
  
end

And that is all the steps required to integrate JRuby within your Waffle Applications. In my next post I will uncover details on how to access registered components from your Ruby based controllers as well as explain the built in conventions that make writing Ruby controllers so easy.

Argible: impromptu presentation at chirb

Tonight I ended up giving an impromptu overview of Argible at the monthly Chicago Area Ruby Group. Utilizing annotations in Ruby code seemed foreign to several of the folks there. So, I quickly went over the Argible source code to illustrate how annotations can be implemented in Ruby (via the Module#method_added(name) callback). This code alone seemed to interest several of the people there.

Additionally, I tried to stress that the concept of using an argument name as meta-data is what I personally find most interesting about Argible. The idea behind Argible should NOT be limited simply to Rails based applications. Anyone have ideas for other situation where this might be useful?

Shoes: Cross-platform Ruby GUI Toolkit

Tonight I attended the monthly Chicago Area Ruby Group. A fellow ThoughtWorker, Josh Cronemeyer, gave an overview of Why's Shoes project.

Many of the attendees seemed to question the need for a Ruby based HTML-like GUI toolkit. While Shoes is by no means ready, nor possibly even intended for, business applications I did find it interesting. A viable Ruby GUI toolkit would improve Ruby adoption even further. Of course JRuby and Swing integration could be sufficient enough to fill that gap (i.e. Swiby).

Argible: testing argible-ized actions

Last week Jay Fields and I were discussing Argible and he asked, "How's testing an action that uses Argible?", the answer ... easy.

Suppose we have the following Controller with an argible-ized action:

class CalculatorController < ApplicationController

  argible(:first => :to_i, :second => :to_i)
  def add(first, second)
    @result = first + second
  end

end

And here is the associated RSpec test:

describe CalculatorController, "add action" do
  controller_name :calculator

  it "should add argument values" do
    post :add, :first => "18", :second => "2"
    controller.instance_variable_get(:@result).should == 20
  end

end

You can see from the test that you do not need to do anything special to test your argible annotated action methods. Just call the action with whatever parameter name and values your action requires.

Argible: automatically set instance variables

As I discussed in my last post Argible makes it easy to resolve method argument values through simple convention. Peter Ryan had an excellent idea of using Argible to automatically set an instance variable's value through simple convention. Have a look at the example below:

class MyController < ApplicationController

  argible(:foo => :@bar)
  def action_one
    p "Bar instance variable was set to: #{@bar}" 
  end

end

Notice that the action method, action_one, has NO arguments. But the argible annotation was passed :foo => :@bar. Argible will interpret that you want the resolved value of 'foo' to be set upon the instance variable named '@bar'. This happens because the symbol on the right hand side is prefixed with the character '@'. Without this Argible will raise an Error informing you that there is no such argument.

Introducing Argible: Simplifing your Ruby on Rails Controllers

Argible is a RubyForge project that was created to simplify Action methods within your Ruby on Rails Controllers. Argible annotated action methods will allow your Actions to define argument. These argument names will be used in conjunction with request parameters to automatically resolve these argument values. Have a look at the FoobarController code below:

  class FoobarController < ApplicationController

    argible
    def action_one(alpha)
      ...
    end

    argible(:date => Date.method(:parse))
    def action_two(date)
      ...
    end

    argible(:date => lambda {|v| Date.parse(v) } )
    def action_three(date)
      ...
    end

    argible(:value => :to_i)
    def action_four(value)
      ...
    end
  end

The first method action_one(alpha) is annotated with the method argible. When the action_one method is executed Argible will intercept the call and look up the request parameter value associated with alpha. Next the action_one method will be called with this resolved value.

The second action, action_two(date), provides an example of how more complex processing can occur on argument values. As in the first example the argument, this time named date, is resolved against the request parameters. The resulting value will then be passed to the Date#parse method. The result from Date#parse will then be used when action_two is called. **NOTE: any method can be used, Date#parse is simply used as an example.

The action action_three(date) provides an example of using a Proc (lambda) as alternative to a named method.

The fourth example action action_four(value) illustrates how you can call methods directly on the string value returned from
the request parameter.

Argible 0.1.0 is available for immediate use from http://rubyforge.org/projects/argible. RDoc can be found at http://argible.rubyforge.org.

RSpec:Rails - How to mock partials when testing a View.

When developing Ruby on Rails (RoR) applications I prefer to use RSpec over the built in testing framework provided with RoR. The biggest benefit is that RSpec easily allows you to test your application layers in isolation (e.g. when testing a Controller you should not be interested in testing the Model). So with that in mind when I am testing a View I am only interested in testing that View and not any of the potential partials that View may try to render.

Suppose we have the View /example/hello_world.rhtml:

<div id="person">
 <h2 class="title">Hello <%= @person.name %></h2>
 <%= render :partial => 'address', :locals => {:person => @person} %>
</div>

Often in RSpec when testing a view such as this the spec ends up testing the partial as well. This is less than desirable because any change to the partial could break test for other views that render that partial. After some investigation I discovered that I could mock the calls to <%= render :partial => 'address'... %>. Have a look at the following spec:

specify 'should call mock and not the actual partial' do
 person = mock('person')
 person.should_receive(:name).and_return('Regan')
 assigns[:person] = person

 # Mock the call to 'render_partial'...
 @controller.template.should_receive(:render).with(:partial => 'address', :locals => {:person => person})

 render '/example/hello_world'
 response.should_have_tag(:h2, :content => "Hello Regan")
end

You can grab a handle to the ActionView through @controller.template as is done in the example above. Then I mock the call to the 'render' method only when the 'address' partial is requested.

As you can see my spec only needs to be concerned with testing the /example/hello_world.rhtml View. The partial will have it's own separate spec. The side effect is that my view specification becomes much more manageable and far less brittle.

Ruby on Cygwin error (*** unable to remap)

I had an annoying issue occuring when running Ruby under Cygwin. The error was reproducable every time that I attempted to run the ri command.

C:\cygwin\lib\ruby\1.8\i386-cygwin\readline.so to same address as parent(0x370000) != 0x2760000
C:\cygwin\bin\ruby.exe (3132): *** unable to remap C:\cygwin\lib\ruby\1.8\i386-cygwin\readline.so to same address as parent(0x370000) != 0x2760000

I was finally able to resolve the issue with the following steps:

1. exit from cygwin


2. enter the dos command prompt


3. cd to you cygwin bin directory (c:\cygwin\bin)


4. run ash rebaseall


5. restart cygwin ... problem solved