Making our RESTful grid editable

In my last post, I showed you how to hook up the new dojo grid component to a RESTful resource in Rails. Now we're ready to make it editable. I promise this will be a shorter post than last time. The key piece is making a new model object to handle our edits. The dojo grid already provides the key pieces to make editing happen; we just need to provide a way to pass the edited values into our Jester-made object to send them along to our application. The way we do this is by creating our own model class which extends dojox.grid.data.Objects. Then we create an instance of this class. This is what the code looks like:

    dojo.declare("MyModel", dojox.grid.data.Objects, {
      beginModifyRow : function() {},
      endModifyRow : function() {} ,
      setDatum: function(inDatum, inRowIndex, inColIndex)
      {
        this.data[inRowIndex][this.fields.get(inColIndex).key] = inDatum;
        this.data[inRowIndex].save();
        this.datumChange(inDatum, inRowIndex, inColIndex);
      }
    });

    var model = new MyModel([{key: "make"}, {key: "year"}], cars);  

I'm definitely doing some hackery to make it simpler for myself here. The beginModifyRow and endModifyRow are dojo methods that get called at the beginning and end of editing a cell. In the normal dojo implementation these methods make a copy of the object being edited so it can be restored if a user cancels the edit. In a final version of this code we would want to clone our Car object when we start an edit, but we're just not worrying about it yet.

The code which actually handles the edit is in the setDatum method. It get's called with 3 arguments, the new value to set, the row index, and the column index. We have an array of cars to which makes it easy to lookup the right row, but how do we know which field is in which column? Well, dojo holds that information for us in the fields property of our model. The fields property provides a method to get a field object by index, and this field object has a key property which is the name of the property of car that lives in this column. This allows us to set the right property of car. Saving our changes back is a snap thanks to Jester. We call save on our car object and we are done.

Finally, we need to make some changes to our structure object to tell it which cells we want to be editable. We'll use dojo's simplest built in editor and make both cells editable. Here's how we do it:

 var structure = [ {
    rows: [[
         {name: 'Make', editor: dojox.grid.editors.Input},
         {name: 'Year', editor: dojox.grid.editors.Input}
    ]]
 } ];

So this is it. We now have an editable dojo grid saving changes by making REST calls into our Rails app.

Using a JS component framework like Dojo (or ext, mootools, etc, etc) in combination with Jester seems like it opens up a new way to approach web application development. I might expound on this in another post.

Dojo Grid + Jester + Rails = RESTful grid goodness

I've been experimenting with Javascript component frameworks lately, and that let me to look at Dojo. With their 1.0 release, they have added what looks to be a very powerful Grid component. I thought it would be fun to see how easy it is to get it talking with Rails. It proved to be not much code at all, and I think, kind of nifty. Here's how to do it.

Create a Rails app with a RESTful service

Not gonna go thru how to make a rails app, I'll assume you know that already. I created a little RESTful service with the scaffold generator something like this:

script/generate scaffold_resource Car make:string year:integer

Install Jester

When I found Jester it was one of those Open Source Moments for me. You know, the ones where you think: "Hey, wouldn't it be cool if you could..." and then Google and find out someone has already done it. Jester is basically ActiveResource in Javascript. The result makes so ridiculously easy to talk to RESTful services it's not even funny. I installed by unzipping the script and dropping jester.js in public/javascripts in my Rails app.

Install Dojo 1.0

Go get it, unzip it, drop it into public/javascripts. Nuff said

Write the code

And now for the fun part :) We'll start with a simple grid that pulls in data by making a RESTful call to our Rails app using Jester. Later on we'll enhance it to make it editable. First thing you need to know about Dojo is that it is CSS driven. This is definitely a good thing IMO, but it does mean you have to include the right CSS or it won't work at all, trust me ;) So make you sure you include the Dojo Grid CSS like so:

 5     <style type="text/css">
 6       @import "/javascripts/dojo-release-1.0.0/dijit/themes/tundra/tundra.css";
 7       @import "/javascripts/dojo-release-1.0.0/dojox/grid/_grid/Grid.css";
 8       @import "/javascripts/dojo-release-1.0.0/dojox/grid/_grid/tundraGrid.css";
 9  
10     </style>

Next, we'll need to include Jester and Dojo:

12     <%= javascript_include_tag :defaults %>
13     <%= javascript_include_tag "jester" %>
14     <script type="text/javascript"
15             src="/javascripts/dojo-release-1.0.0/dojo/dojo.js"
16             djConfig="parseOnLoad: true"></script>

Including Jester is just a matter of including using the standard javascript_include_tag helper, but dojo is a little wierd. You'll notice the djConfig attribute for starters. How does this even work? djConfig is not even a valid attribute for a script tag, right? As best I understand it, and someone please jump in if I'm wrong, dojo has a parser of it's own that comes along after your page load sand does things to it. This let's you add dojo components to your page "declaratively", or in html, instead of have to use so much javascript. Kind of interesting.

Now let's look at the script block that sets up the objects our grid will need:

18     <script type="text/javascript">
19     dojo.require("dojo.parser");
20     dojo.require("dojox.grid.Grid");
21     dojo.require("dojox.grid._data.model");
22
23     Resource.model("Car");
24     cars = Car.find("all");
25
26     var model = new dojox.grid.data.Objects([{key: "make"}, {key: "year"}], cars);
27
28     var structure = [ {
29        rows: [[
30             {name: 'Make'},
31             {name: 'Year'}
32        ]]
33     } ];
34
35
36     </script>

The first thing you'll notice is those dojo.require statements. These are how you tell dojo to go get all of the pieces it needs. Dojo is broken down into lots of individual javascript files, and while you could just include them all in script tags, that would be kind of a pain. dojo.require basically says "go get this piece and all of it's dependencies". It makes it easier to use some of dojo and not all of dojo as well.

Next we see Jester in action. Kind of puts dojo to shame from an ease of use standpoint, doesn't it? You tell Jester which model you want, and it makes a javascript class for you. We then call find all and it gives us back an array javascript proxy objects with the fields and methods you would expect. Like I said, ridiculously easy. There are options to have it do find (and save) asynchronously as well, which you would probably want to use for a real application.

Next we setup some objects our dojo grid needs. The first is a model, it tells dojo where to get it's data from. We're able to use of the built in types of models, dojo.grid.data.Objects. This kind of model will display an array of Javascript objects, which, conveniently enough, is exactly what we got back from the call to find. We have to give it a little more information, though, namely what properties to display in which columns of our grid. This is what we're doing in the first argument to the constructor. The second argument is our array of cars we got back from the call to Car.find("all").

Finally, we have an object that tells how we want our grid organized. I have to say this seems a lot more complicated than I'd like. It seems to me sometimes dojo is more focused on making the hard things possible than making the simple things simple. So I'm not even going to try to cover all the details of the structure object here, but briefly dojo grid structures consist of an array of views which have an array of rows which have an array of subrows. Phew. I think it would be possible to come up with a simpler structure object for simpler cases, but that would require more dojo-fu than I have yet.

At last, we're ready to put in the html for our grid. Here it is:

42   <div id="grid" dojoType="dojox.Grid"

43        model="model" structure="structure"
44        autoWidth="true" autoHeight="true">

45   </div>

Not much to it is there. Notice how we can set properties of our grid with html attributes. This is what the dojo parser does for us, as I understand it. Here we're passing in the model and structure we created in our script block.

So this is all that's required to use the dojo grid component and have it pull data from a REST service implemented in Rails. In my next post I'll show you how to have it be editable and save it's data using thru REST as well. It's easier than you might think.

Debugging a JRuby on Rails app with jruby-debug and NetBeans

We've been working on the java port of ruby-debug for awhile and it's getting perilously close to usable. And with the latest builds of NetBeans, you can actually use the NB ruby debugger with it. If you're very brave, you can try it for your yourself. Be warned, it's still a work in progress, but here's how to get started:

1. Check out jruby from trunk and build it. You'll need java and ant, but if you're interested in jruby chances are good you have those already. It's super easy to build, check it out from http://svn.codehaus.org/jruby/trunk and do ant dist and you're good to go.
   
2. Check out jruby-debug from http://debug-commons.rubyforge.org/svn/jruby-debug/trunk. In this directory, do rake install_gem. This will compile and build a jruby version ruby-debug-base, which ruby-debug (command line rdebug debugger) and ruby-debug-ide (which NetBeans and Eclipse use) both depend on.
3. Check out ruby-debug-ide from http://debug-commons.rubyforge.org/svn/trunk/ruby-debug-ide. Then do a rake gem to build the gem and gem install pkg/ruby-debug-ide-0.1.8.gem to install it.
   
4. Grab a copy of NetBeans daily builds ruby ide from here: http://deadlock.netbeans.org/hudson/job/ruby/
5. Fire up NetBeans like with some extra command line switches: ./netbeans -J-Dorg.netbeans.modules.ruby.debugger.force.rdebug=true -J-Dorg.netbeans.modules.ruby.debugger.fast.not.required=true
   The first tells NetBeans to always use the fast debugger even tho the classic debugger is what appears selected in the UI. The second tells NB to ignore the fact that the classic debugger is selected and allow us to debug a rails app anways. These flags were just added to allow us to play with jruby-debug in NetBeans for now, they won't be necessary once jruby-debug matures a little and full support for it comes into NB.
6. In NetBeans Tools | Options be sure and have your ruby interpreter pointing at the jruby you built from trunk in Step 1.

You should now be able to debug Ruby and ROR apps using the fast ruby debugger inside of jruby. Like I said, this is all very experimental. All these steps will go away in the next few weeks or months and jruby-debug, jruby, NetBeans, ruby-debug-ide do releases.

Things which seem to work ok:

• setting breakpoints
• looking at variables (global and local)
• watches

A little flaky (tho it may already be fixed by the time you read this):

• Stepping over some code in Rails
• Stepping out of a method

Finally, big time kudos to Martin for kicking this whole thing off and Peter for knocking out bugs and implementing more features every hour just about. It's definitely looking close now.

Avoiding Helpful Tools Considered Stupid

Rarely does a blog post get me all fired up like Giles Bowketts here. As part of the team working on improving debugging support for JRuby, it probably struck a particularly personal chord. Nothing like having your hard work publicly ridiculed to get you exicted. I might have ignored it, and maybe I probably should, but the post contains some truly exceptional BS that needs to be addressed.

First off, it claims to inspired by a good friend of mine. So Giles, to quote from that famous vice presedential debate: I know Jim Weirich, and you sir, are no Jim Weirich! Ok, so maybe Giles didn't actually claim to be Jim Weirich, but the fact that he even attributed Jim in any way while spouting such blatent poppycock just shouldn't be.

As part of my job I have the incredible good fortune to pair with Jim on a Rails project. At the risk of pointing out what should be obvious, we do write test cases. And, it's true, when we first started working together, we did not use a debugger. Most of the time, we didn't need one. But every so often, we would have a situation where we couldn't understand what some code was doing. More embarrassing still, sometimes it was even code that we wrote.

So, when confronted with such a situation, when we couldn't think of any more test cases to write, we would add statements like this to our code "puts DBG: #{some_value_we_want_to_see}". Wow, perty high tech, eh? And it worked. We could always solve our problem this way. Jim even had a little rake task that would comb thru the code to find DBG: in our code so we could easily remove these when we were done.

Then one day I got tired of us typing DBG: in our code and I said something like "Let's try using rdebug". And guess what: rdebug was often handier than adding puts statements to our code. We could inspect all kinds of stuff. Sometimes it helped us learn more about how Rails works, especially when it did things that were, umm, a little unexpected. It was a good thing. So much so, in fact, Jim spent some time working on getting it working better with emacs so it was even easier to use.

And, hard to believe tho it may be, it did not cause us to write less test cases. Every time we learned something while debugging, we could go back and write a test case which documented our learning. In the end it helped us to write more and better test cases because we were actively trying to do so.

So it should be obvious, but since it didn't seem to be I'll state it: debuggers are tools. Like any tool, if it helps you do your work better, you might want to use it. If it doesn't you probably shouldn't. Using a tool does not lead to bad habits, bad habits lead to using a tool incorrectly. And it's worth pointing out, the technique of classifying a technology or tool as bad because it can be used incorrectly is exactly the argument that I hear made against metaprogramming and run time type checking. Kind of ironic.

Geeky Fatherhood Moment

Some dads live for moments like when their son can beat them at basketball or throw a touchdown pass at a high school football game. Since my family seems to share my, ahem, lack of athletic prowess, I mostly get my "dad pride" fixes in different ways. For example, today my 10 yr old son asked me a question that nearly brought a tear to his old man's eye:

"Dad is there a job you can have when you grow up where you use Gimp?"

:)

Spring Rails Plugin 0.1

Well, I finally checked in my code for a Spring Rails plugin. Consider it pre-alpha at this point. It's unit tested, and I made a simple example app to prove that it works. But that's about it. So if you find it useful, try it out and let me know so I can decide where to go with it next.

To install the plugin:

script/plugin install svn://rubyforge.org/var/svn/jruby-extras/trunk/rails-integration/plugins/spring

You'll need to get a basic Rails application working with the goldspike plugin in order for the Spring plugin to be of use. Currently it loads the Spring ApplicationContext by getting it from the ServletContext (which assumes you are using the Spring context listener to put it there). So if you're not running Rails in a servlet engine it doesn't work. If there is real interest in having the plugin be able to get an app context from somewhere else I'll look at supporting that down the road.

For an example of how to use it in a controller, see my previous post.

Why you shouldn't use it

If you're a Java programmer new to (J)Ruby and are thinking: "Awesome, I'll use Spring in all my Rails apps because Spring is awesome!" you need to hold up a second. Spring is awesome -- when you are developing Java applications. But in Ruby, dependency injection turns out to be unnecessary a whole lot of the time. This is because the Ruby language allows you to change things in a more straightforward way. And even if there were cases where you needed DI in Ruby there are probably better choices. I see the Spring plugin being useful where you have existing J2EE code wired together with Spring and want to front end it in JRuby on Rails. So use this plugin if you need it, but if you don't, then don't.

Don't take my word for DI and Ruby, my friend Jim had this blog post about it after our IM conversation. See the comments where other Ruby heavyweights weigh in on the subject.

eRubyCon was awesome

Just wanted to get in a blog, albeit a week and a half late, about eRubyCon. It was an awesome conference; I felt honored being involved as a speaker doing a presentation on JRuby. Being among such incredible speakers as Jim Weirich, Glen Vandenburg, Stuart Holloway, and many others made me a little like the scene in Wayne's World where Wayne and Garth meet Alice Cooper: I'm not worthy!

As far as I know, this is the first conference specifically devoted to Ruby in the Enterprise. If all you've gotten is the 30 second soundbytes about Ruby and Rails this may sound like an oxymoron, but it's not. The other speakers, particularly Glen in his "Enterprise Schmenterprise" keynote made this point eloquently. Ruby, because of it's excellence at producing easily understood and therefore much more maintainable code, is the perfect language to develop the kind of applications thought of as "enterprisey". Glen: "Enterprises aren't ready for Ruby, they're desperate for it".

Stuart made a point in his blog about this too. His series on Ruby vs Java myths made the point that Ruby is actually better for large applications than for small ones. Definitely worth a read.

Finally a big Thanks! to Joe at Edgecase for putting this together. Joe, I know it was a lot of effort time and finance wise but I hope the community can grow enough to make this a viable yearly conference: the word about Ruby really needs to get out in the enterprise development area. For their sake and ours.

include Spring

I've gotten a little farther with my JRuby on Rails Spring integration code. I think I have what may make the beginning of a Spring plugin for JRuby on Rails. Here's the code for the Spring module. This is my first foray into metaprogramming in Ruby, I'd welcome any feedback.

# spring.rb
# June 20, 2007
#


module Spring
  include Java
  import javax.servlet.ServletContext
  import org.springframework.web.context.WebApplicationContext
  import org.springframework.web.context.support.WebApplicationContextUtils
  
  def spring_bean (bean)
    class_eval "def #{bean.to_s}; application_context.get_bean(\"#{bean.to_s}\"); end;" 
  end
  
  # dunno if there is a better way to do this.  I need the spring_bean method
  # to become a class method on the includee, but application_context needs to be
  # a normal instance method
  def self.append_features(includee)
    includee.extend(Spring)
    includee.class_eval do
      def application_context
        WebApplicationContextUtils.getWebApplicationContext($servlet_context)
      end      
    end
  end
end

This gives you a handy spring_bean method in any class where you've included Spring. The spring_bean method will then dynamically add an accessor to the class you use it in. This is what it looks like in a controller:

class TestSpringController < ApplicationController
 include Spring
 spring_bean :descriptor1
 def showcontext  
   render_text descriptor1.displayName
 end

end

Obviously to have this working you need several things. You need to have the goldspike plugin (from SVN trunk as per my earlier post). You also need to have Spring and its dependent jars in your WEB-INF/lib. I just copied em in for playing around purposes, with a little tweaking of my conf/war.rb file I could probably make goldspike fetch them. And lastly, it assumes you have an applicationContext.xml in WEB-INF, and that you have the Spring ContextLoaderListener declared in your web.xml.

Wow, that's a lot of trouble, why the heck would I want to do all that? What's this all for anyways? First of all, if you need this you probably don't need to ask, you know who you are. No, I'm not even trying to suggest using Spring for greenfield JRuby on Rails applications. But if you need to do heavy Java integration or you have an existing Spring application you want to front end in Rails, this kind of thing could end up being quite handy. This is my situation: I have a pretty large Spring/Hibernate/Tapestry app and I'd like to make moving to JRuby on Rails a viable option. Rather than replace everything whole hog, I'd like to be able to leverage working Spring services easily from Rails. As you can see, doing this should be a piece of cake.

Spring + JRuby on Rails

I've only been threatening to do this for a year, but I finally added the necessary stuff to have JRuby on Rails talking to Spring. There's a lot more to come here, but this controller code demonstrates being able to get ahold of a Spring WebApplicationContext in a Ruby on Rails controller.

class TestservletController < ApplicationController
  include Java
  import javax.servlet.ServletContext
  import org.springframework.web.context.WebApplicationContext
  import org.springframework.web.context.support.WebApplicationContextUtils
  
  def showcontext
    app_context = WebApplicationContextUtils.getWebApplicationContext($servlet_context)
    render_text app_context.display_name
  end
end

In order for this to work, you'll have to use the very latest goldspike-snapshot plugin from SVN trunk. I just checked in the code to expose $servlet_context earlier today. Obviously this code will only work using a servlet container, and you'll need to have Spring and necessary deps in WEB-INF/lib and have the Spring context loader listener in your web.xml. From here, my next step is some metaprogramming to allow you to add spring bean accessors into your controllers.

API unickifying with JRuby

So I've been putting together some code examples for RubyCodeCamp in Columbus in a couple weeks. Quite awhile back I ran into a situation where I wanted to read an Excel spreadsheet from Ruby. At the time, there was no good way to do it in Ruby (MRI) and so I used Java and the nifty POI library. I thought this might be make for a nice example in JRuby. So I fired up jirb and started coding. In a few minutes I was reading data from a spreadsheet:

require 'java'

require '/home/ccnelson/java/poi/poi-2.5.1-final-20040804.jar'

include_class 'org.apache.poi.poifs.filesystem.POIFSFileSystem'

include_class 'org.apache.poi.hssf.usermodel.HSSFWorkbook'
include_class 'org.jruby.util.IOInputStream'

File.open("/home/ccnelson/documents/Invoice15.xls") do |f|
workbook = HSSFWorkbook.new(IOInputStream.new(f))
puts "cell 0,0: #{workbook.getSheetAt(0).getRow(0).getCell(0).getStringCellValue}"

end

There's some nice stuff going on. I really like being able to just include a jar and start using it. Still, using the POI API in Ruby looks rather icky -- (actually, it started even worse than this, but Charles Nutter was on #jruby and was kind enough to tell me about IOInputStream). After looking at this code for a minute I started thinking and it came to me: "Hey this is Ruby. We can do anything we want!"

I started with that ugly getStringCellValue at the end. It would be nice if we could give cell a to_s and do away with that. Well, guess what, since this is Ruby, I can just open HSSFCell and do it:

require 'java'

require '/home/ccnelson/java/poi/poi-2.5.1-final-20040804.jar'

include_class 'org.apache.poi.poifs.filesystem.POIFSFileSystem'
include_class 'org.apache.poi.hssf.usermodel.HSSFWorkbook'
include_class 'org.jruby.util.IOInputStream'

include_class 'org.apache.poi.hssf.usermodel.HSSFCell'

class HSSFCell
def to_s
getStringCellValue
end
end

File.open("/home/ccnelson/documents/Invoice15.xls") do |f|
workbook = HSSFWorkbook.new(IOInputStream.new(f))
puts "cell 0,0: #{workbook.getSheetAt(0).getRow(0).getCell(0)}"

end

Cool! Even though HSSFCell is a java class, because I am using it from JRuby I can open it up and stick methods on it. This got me excited. What do I really want this API to look like? I think I'd really rather be able to access my spreadsheet cells using a simple 2 dimenional array. I mean, that's really what they are for my purposes. And guess what? In Ruby, the [] operator, like everything else in Ruby, is just a method. And if it's just a method, well I can abuse... err.. bend it to my own nefarious purposes. Bwah ha ha hah ha hah ha ha..

Oops, got a little carried away there. Ruby coding will do that sometimes. Back to the task at hand:

require 'java'

require '/home/ccnelson/java/poi/poi-2.5.1-final-20040804.jar'

include_class 'org.apache.poi.poifs.filesystem.POIFSFileSystem'
include_class 'org.apache.poi.hssf.usermodel.HSSFWorkbook'
include_class 'org.jruby.util.IOInputStream'

include_class 'org.apache.poi.hssf.usermodel.HSSFCell'

include_class 'org.apache.poi.hssf.usermodel.HSSFRow'
include_class 'org.apache.poi.hssf.usermodel.HSSFSheet'

class HSSFCell
def to_s
getStringCellValue
end

end

class HSSFSheet
def [] (index)
getRow index
end
end

class HSSFRow

def [] (index)
getCell index
end
end
File.open("/home/ccnelson/documents/Invoice15.xls") do |f|
workbook = HSSFWorkbook.new(IOInputStream.new(f))
spreadsheet = workbook.getSheetAt(0)
puts "cell 0,0: #{spreadsheet[0][0]}"

end

Nice! This for me is one of the killer features of JRuby. A lot of scripting languages will let you access the Java APIs in a more light weight language. But because of the features of the Ruby language, it becomes so easy to modify APIs to suit your needs, desires, and insane urges.

Welcome to my new blog

I was getting kind of tired of JRoller, so I decided to move. Welcome to my new digs!

class InventoryController
end