validates_presence_of :purpose : Tag bug, everything about bug

Testing PUT requests with Culerity

Sun, 31 Jan 2010 21:22:00 +0000

One major pain at testing with culerity so far was a HtmlUnit bug that causes a ScriptException with PUT AJAX requests in jQuery. When you tried to test an update you got a “java.lang.IllegalArgumentException: The content cannot be null”. Fortunately, this bug is fixed now. With latest HtmlUnit build culerity should run fine, and I tell you how.

I assume you have culerity installed already. If not, follow these instructions for testing Rails apps or these for testing Couchapps.

1. Make sure you have up-to-date versions of celerity and culerity:
$ jruby -S gem install celerity #(gives you celerity-0.7.8)
$ gem install culerity –source http://gemcutter.org #(gives you culerity-0.2.7)

2. Get the latest HtmlUnit nightly build:
$ wget http://build.canoo.com/htmlunit/artifacts/htmlunit-2.7-SNAPSHOT-with-dependencies.zip
$ unzip htmlunit-2.7-SNAPSHOT-with-dependencies.zip
$ cd htmlunit-2.7-SNAPSHOT-with-dependencies/lib
These are the jar files you need to copy into your celerity gem.

3. Find your celerity gem and copy the files:
$ jruby -S gem which celerity
$ cp * PATH_OF_JRUBY_INSTALLATION/lib/ruby/gems/1.8/gems/celerity-0.7.7/lib/celerity/htmlunit

4. The new HtmlUnit needs JQuery 1.4, so you need to upgrade if you haven’t done already. There’s a backwards compatibility plugin for 1.3 if this gives you trouble.

Have fun!

Couchapp / Culerity glitches, part 1

Wed, 04 Nov 2009 10:07:00 +0000

Do you know what's behind these buzzwords: CouchDB / Couchapp / Sammy.js? Not really? Then please look at this article now: Sammy.js, CouchDB, and the new web architecture. The title says it all.

This setup happens to be the field of my diploma thesis, friendly sponsored and supported by Upstream. During the next months I'll develop a super duper thing with these technologies, and then I'll write 80 scientific pages about it. Yees, I'm not that much looking forward to the second part! Until then, I'm planning to semi-regularly blog about my findings.

I'm not allowed to share the code before I have the diploma in my hands. But, because my workmate Frank Proessdorf is so jealous of what I do, he and I started working on an app with a similar setup on our Upstream Research Fridays, to try things out. Here it is. Don't expect anything yet.

Today I'm going to tell you about some details of my testing setup. My *cough* supervising tutor Alexander Lang already wrote down all there is to know yet about Test-Driven Development with Cucumber-Culerity-Celerity and Couchapps.

But there are a few things that will make your life hard, when the almost perfect Rails testing world has spoiled you as much as me. One thing is that we have to deal with a lot of asynchrony. Sammy renders the page, loads the data from the couch, and whenever the data is there it gets rendered into the page. The best way to do this is via callbacks. I'm going to write another blog post about that soon.

In the integration test the problem is that celerity doesn't behave as it claims it does:

$browser.wait

is supposed to make the test wait until everything is rendered completely. But for whatever reason it doesn't. The result is that your test fails because it searches for your expressions in an unfinished page.

Because of that, in culerity we need something like:

sleep 0.4

after every follow, press and go-to-path step. When using culerity in a Rails environment, this usually is enough. Sammy behaves a bit more unpredictable - it sometimes takes more than a whole second until everything is loaded.

Solution? We can either increase the sleep time a lot, but that's not very nice, the features need long enough to run as it is. Fortunately we can use another method that's build into celerity: wait_while.

I created a div "spinner" somewhere in index.html:

 <div id="spinner"></div>

You can also add an actual spinner gif here. Just take care to place the div outside of your sammy element selector ("#main" by default), because this div gets replaced all the time.

We need to show that div before every route that gets run. In application.js:

before(function() {
  $('#spinner').show();
});

And we need to hide it after your rendering is completed. I haven't found an ideal solution where to do that, it depends on the application you are writing. As a quick and dirty fix, you can add it as a last line in sammy's partial function, in sammy.js:

partial: function(path, data, callback) {
  //...
  $('#spinner').hide();
},

I prefer to have more control about when I hide it, as my partial calls sometimes have nested callbacks. So I put it in application.js, resp. in my controllers, after each render call or in the partial callbacks. I admit this still sucks a bit.

Finally, amend the cucumber step:

When /I wait for the AJAX call to finish/ do
  sleep 0.2
  puts 'Waiting for page to load ...' if $browser.div(:id, 'spinner').visible?
  $browser.wait_while { $browser.div(:id, 'spinner').visible?} 
end

The browser still needs to sleep a bit before it actually finds the spinner div. But with this step in my common_culerity_steps.rb, the features finally run smoothly.

Comatose bug when creating pages in migrations

Tue, 27 Oct 2009 22:27:00 +0000

Comatose is a micro CMS, easy to embed in your Rails app, ideal when the customer wants to update her FAQ once in a while. I work on a few projects where comatose is integrated, and it's been the second time now that one specific problem has given headaches to me and my colleagues. Time to document the solution.

Comatose has a hierarchical structure. All the pages are children of the comatose root page, which is usually not in use. This root page is created by the migration AddComatoseSupport. When we add comatose to a project, we usually create another migration, where some child pages are created and populated (because the customer usually already knows what pages she wants). This can look like this:

root = ComatosePage.find_by_title('Home Page')
faq = ComatosePage.create(:title => 'FAQ', :author => 'System', :body => "Text goes here.", :parent_id => root.id

All will be fine if you run the AddComatoseSupport migration first, and then the other one. If you run both of them in one go, all will look correctly first, too. But then - try to access the application and you get "a nil object when you didn't expect it!" A look in the database will tell you that your root page and your FAQ page are both there - but the slugs (needed to access the pages) are nil. Why is that?

The answer: The class ComatosePage gets overwritten in the AddComatoseSupport migration, to make sure the comatose root page can be created (they are invalid without parent_id). But if you have another migration following this one, where you create a couple of comatose pages, they still are instances of that overwritten class. Especially the before/after filters from the original ComatosePage aren't evaluated. In those filters the slug fields are meant to be populated, so they are nil.

First soluton: Define a class ComatoseRootPage instead, so you won't override anything.

Second and much easier solution: Remove the class redefinition altogether, for the root page just do

ComatosePage.new(...).save(false)

See on github.

Unfortunately the comatose project is not updated very often, so this bug is still unsolved in the generated migrations.