Semergence

Thinking about REST or need to address some lingering concerns about adopting REST? I found the article Addressing Doubts about REST full of pragmatic, down to earth answers and advice for comparing REST and WS-* (or, RPC).

Nothing new, but a solid collection of answers to how you should think about REST and how you should apply it to your system.

I especially appreciated how the author points out that if you are worried about transactions across your systems, that’s probably a design smell and you want to re-think your approach. Never expect that transactions will work reliably across many systems. Instead, build in logic to recover from error states. This is not a REST issue, but instead a large system design issue. REST simply makes it easy to pass the state of your resources between systems.

I’ve been using RSpec with my latest project, and it’s a welcome change from the traditional Test::Unit for Ruby.

RSpec is a more natural way to write tests for your software. It seems to be much easier to compose tests, and anything that makes testing easier is OK in my book.

A specific example of why I’m falling for RSpec:

You can easily group common tests together, and include this grouping in your main tests. Of course you can do this in any number of ways with Test::Unit, but RSpec makes it so clean and obvious.

Here’s an example of a very common set of tests that I need to run again all my controllers:

describe "Requires Authorization", :shared => true do
  describe "when not logged in" do

    describe "when accessing index page" do
      it "should redirect to login page" do
        get 'index'
        response.should redirect_to(new_session_path)
      end
    end

    describe "when accessing new database page" do
      it "should redirect to login page" do
        get 'new'
        response.should redirect_to(new_session_path)
      end
    end

    describe "when accessing show database page" do
      it "should redirect to login page" do
        get 'show'
        response.should redirect_to(new_session_path)
      end
    end

    describe "when accessing destroy database page" do
      it "should redirect to login page" do
        get 'destroy'
        response.should redirect_to(new_session_path)
      end
    end

  end
end

In each of my controller tests, I only need to include:

describe DatabasesController do

  it_should_behave_like "Requires Authorization"

Take a look at that! Reads just like English, I would say.

If you haven’t made the jump to RSpec, I’d seriously recommend you give it a shot. You don’t need to abandon all of you existing unit tests. Both sets of tests will run just fine in your Rails project.

I’ve been reading through Advanced Rails Recipes, and so far I like the book. It has a nice collection of tips and tricks for the experienced Rails developer. This is the kind of book that you have to quickly scan through when you get it, so you know what tips are available. Remembering that the book has the solution for your problem at hand is the tough part.

One common requirement for web frameworks is being able to handle nested forms on submit. It’s too common to present to the user a complex form, representing many different, usually nested, objects. The difficulty isn’t really in displaying or formatting the nested HTML form itself, but in handling the submit. How do you save or update all of the objects easily and efficiently? What if there’s an error?

The excellent and always useful RailsCasts had a series of episodes that handle the nested form issue (Complex Forms 1, Complex Forms 2, and Complex Forms 3).

There’s a problem with their approach, and it’s cause is validations. There’s a chicken-and-the-egg problem, in that if you wish to add a validates_presence_of :parent_id in your nested child object (which you should, because it helps to enforce referential integrity), then you will not be able to save the parent and the child objects with a simple call to parent.save

Remember, the whole point of the RailsCasts, and this general problem, is that we wish to easily handle nested forms when submitted. We want to create a parent and its children with one simple submit.

Here’s what happens, thought:

1. class Parent has many Children, class Child belongs to Parent. Class Child also validates_presence_of parent_id
2. create a new parent
3. create a new child with parent.children.build()
4. call parent.save
5. the save will fail, because child is invalid, because parent_id is null, because validations for children are run before parents are saved (and thus, create a PK)

(oh, and did you know that when saving a new parent that has new children, the parent will cascade the validations down to the children automatically? I didn’t know this was automatic)

Getting back to Advanced Rails Recipes, the author included the Complex Forms examples from RailsCasts. And there’s no mention of this validation issue. So, being the good beta book tester that I am, I created an errata suggesting the mention this problem with validations.

Note, someone with the name of Mina Naguib mentioned this problem in the comments for Complex Forms 1, although I haven’t tried it out (and sorry for not linking to the comment, the RailsCasts blog doesn’t provide an id for each comment).

So, IMO, this is a common requirement of web frameworks that I don’t believe Rails has solved cleanly and elegantly yet. I’ll keep looking around for a good solution. Suggestions welcome!

• The Best Tools for Visualization - ReadWriteWeb
  (tags: data visualization graphics)

• Labnotes » json_request: handling JSON request in Rails 2.0
  (tags: rubyonrails json)

• generatedata.com
  (tags: database data)

• ELASTRA - The Infinite Database
  (tags: database snb)

• Text* Snippets: Add all new files to Subversion [awk] [grep] [svn] [subversion]
  (tags: subversion)

• YouTube - Web 2.0 … The Machine is Us/ing Us
  (tags: web2.0 video)

• Tom ten Thij’s homepage: RSpec plain text story runner on a fresh rails app
  (tags: rubyonrails testing)