Here’s a little form for sending an XML post in OpenLaszlo. This is a useful little snippet of code, since as if you get one little content header or something wrong, Rails will be unforgiving with its powerful, yet strict implementation of REST.

What the app looks like (enter text in the top, click the button, response is printed in the lower box):

blockquote.code {
font-style: normal;
font-family: Monaco,monospace;
font-size: 10px;
border: solid 1px #aaa;
padding: 6px;
background-color: #eee;
color: inherit;
overflow:auto;
margin: 10px 0px;
}

The code:

<canvas title="Test Post" proxied="false">
  <dataset src="http:/projects.xml" name="ds"
    ondata="response.setAttribute('text'this.childNodes[0].serialize())"/>
  <simplelayout spacing="4"/>
  <edittext id="postdata" multiline="true" width="400" height="200"
     text='&lt;project&gt; &lt;title&gt;XXX&lt;/title&gt; &lt;/project&gt;'/>
  <button text="post">
    <handler name="onclick">
    ds.setQueryParam("lzpostbody", postdata.text);
    ds.setAttribute("querytype", "POST");
    ds.setHeader("Content-Type", "application/xml")
    ds.doRequest();
  </handler>
  </button>
  <edittext id="response" multiline="true" width="400" height="280"/>
</canvas>

Rails enables web services by default, which is pretty awesome, and I’ve been relying on that for a while. It is pretty nifty how Rails will magically parse XML post parameters, create an in-memory object and then save that object to the database without your having to write one line of code. However, when the magic fails it can be pretty hard to debug. I found it useful to run basic tests on the command line using curl (hearing the voice of Zach Moazeni in my head saying: “test your assumptions.”)

Below is a writeup of the set of curl commands and sample output for testing the default Rails XML REST APIs. This can serve as a cheat sheet for the experienced or an introduction for folks new to rails who want a basic understanding of the default webservice APIs.

Create an app, by typing the following commands into your terminal:


$ rails basic_app
$ cd basic_app
$ ./script/generate scaffold project title:string description:text
$ rake db:migrate
$ ./script/server

In Rails 2.3, you also need to added the following line to the top of app/controllers/projects_controller.rb (This will allow external access to the APIs.) You can make this change while the server is running, btw.


skip_before_filter :verify_authenticity_token

Leave that window open where you can see it, since it will output useful stuff from the log. Then in another terminal window, experiment with the following commands to interact with your application APIs.

blockquote.code {
font-style: normal;
font-family: Monaco,monospace;
font-size: 12px;
border: solid 1px #aaa;
padding: 6px;
background-color: #eee;
color: inherit;
overflow:auto;
margin: 10px 0px;
}

Create

POST /projects.xml

Create a project object based on the XML representation given in the post body and save in the projects database table.

$ curl -X POST -d "<project><title>Awesome</title><description>This is an awesome project.</description></project>" -H "Content-Type: application/xml" http://localhost:3000/projects.xml

<?xml version="1.0" encoding="UTF-8"?>
<project>
  <created-at type="datetime">2009-06-21T10:13:43-07:00</created-at>
  <description>This is an awesome project.</description>
  <id type="integer">6</id>
  <title>Awesome</title>
  <updated-at type="datetime">2009-06-21T10:13:43-07:00</updated-at>
</project>

Index

GET /projects.xml

This returns a list of all of the projects in the database with an automatically generated XML representation.

$ curl http://localhost:3000/projects.xml<?xml version="1.0" encoding="UTF-8"?>

<projects type="array">
<project>
  <created-at type="datetime">2009-06-21T10:13:19-07:00</created-at>
  <description>This is an awesome project.</description>
  <id type="integer">1</id>
  <title>Awesome</title>
  <updated-at type="datetime">2009-06-21T10:13:19-07:00</updated-at>
</project>
<project>
  <created-at type="datetime">2009-06-21T10:13:43-07:00</created-at>
  <description>New information here</description>
  <id type="integer">2</id>
  <title>Awesome</title>
  <updated-at type="datetime">2009-06-21T10:49:21-07:00</updated-at>
</project>
</projects>

Show

GET /projects/1.xml

This returns an xml representation of the project with id #1

$ curl http://localhost:3000/projects/1.xml<?xml version="1.0" encoding="UTF-8"?>

<project>
  <created-at type="datetime">2009-06-21T10:45:19-07:00</created-at>
  <description>This is an awesome project.</description>
  <id type="integer">8</id>
  <title>Awesome</title>
  <updated-at type="datetime">2009-06-21T10:45:19-07:00</updated-at>
</project>

Update

PUT /projects/1.xml

This modifies the project with id #1

curl -X PUT -d "<project><description>New information here</description></project>" -H "Content-Type: application/xml" http://localhost:3000/projects/1.xml

RSpec for View Helpers

  • To test a view helper, you need to test the plugin in the context of a rails app
  • To verify that you can put the following code into your spec_helper.rb (or just use rspec-plugin-generator by Pat Maddox which will generate this code for you)
    begin
      require File.dirname(__FILE__) + '/../../../../spec/spec_helper'
    rescue LoadError
      puts "You need to install rspec in your base app"
      exit
    end
  • By convention, helper examples live in spec/helpers/ then their dependencies will get magically included.   David Chelimsky notes

    All directories under spec/ are potentially magic – rspec will always
    look at spec/:directory/:filename and see if it has an example group
    type registered for whatever directory is. So if there *is* a foo
    example group type, it will be used for any spec file in spec/foos

  • If you put helpers elsewhere, then you need to declare their type (or manually include dependencies)
    describe AppletHelper, :type => :helper do
  • To send params in your test, you can just define them before calling your view helper.  For example:
    describe DogHelper do
      it "should bark" do
        params[:debug] = "foo"
        html = helper.bark
        html.should have_tag("script")
      end
    end

What do you do when some behavior depends on RAILS_ENV?

  • It’s not a good practice to switch around RAILS_ENV in the test framework
  • Better idea is use a method to check it and then stub that out
  • Here’s an outline:  gist from Zach
  • Here’s what I did: EnvChecker, code and example

Stub tip

If you stub something and it appears not to be working, check when your module, class or method is loaded or created.  Dynamic languages can be challenging.  (thanks David)

References

For more information, see

These lessons learned while developing RSpec examples for a bug fix in openlaszlo_plugin with help from Zach Moazeni, RailsBridge mentor, and David Chelmsky, on the RSpec forum.