Anyone subscribed to an RSS feed for this blog should update their feed URLs. The old ones should still be working for now, but it won't be long until I remove support for them and only support the new ones. So, consider yourselves warned.

I'm due to give a presentation on OpenID at the upcoming Missoula Web Discussion Group meeting and figured before I do a presentation on it, maybe I should actually implement it somewhere first. I've been meaning to implement OpenID on the blog for a while and figured that volunteering to do the presentation would light the proverbial fire under my you-know-what.

However, even longer than I've been wanting to implement OpenID on the blog, I've been meaning to convert it all over to a RESTful routing architecture. So, I sat down this morning with the intent to do that first, then work on the OpenID stuff. There was one unexpected hurdle though.

Writing the blog software myself was, in part, a practice Rails project that I started a long time ago, and I haven't really done much to update or improve the code since the original writing. It seems my coding practices have improved considerably since then. As soon as I opened up the first model I knew I had more to do. It was f'ugly, to put it nicely, and I wasn't about to start trying to build new functionality on top of that garbage. So, some major refactoring took place this morning before I could even start on the RESTful refactoring.

So, now it's late afternoon, I haven't refactored as much as I'd like but it's much better and the routes are now RESTful. However, I haven't even started on the OpenID stuff yet. Ugh.

But anyway, the RESTful upgrade meant that the RSS URLs needed change too. I managed to keep the old feed URLs working, but I'm not going to leave that in long. So, update your RSS client with the new addresses if you want to keep getting updates.

Comments: 0 [add comment]

ARID has a new home of it's own on RubyForge, and version 0.4 and improved documentation is now available.

ARID (ActiveResourceIntegrationDSL) is a Ruby on Rails plugin providing methods for simple and DRY integration testing of conventions-compliant RESTful Rails applications.

This version contains significant changes to how test methods are formatted and is NOT backwards compatible with tests for prior versions.

Changes

  • :expected_response option is now just :expects
  • creates_ and updates_ methods no longer go through the new and edit actions.
  • added builds_ and edits_ methods that do continue on to creates_ or updates_ if passed a :params hash.
  • renamed reads_ method to shows_ and aliased lists_ to shows_.
  • renamed deletes_ to destroys_.

Bug Fixes

  • significant updates to previously sparse documentation, now RDoc-able.

Ehancements

    added option to add HTTP headers to requests
  • added support for textarea and select fields
  • added support for nested resource paths

This version is currently being used in several production Rails 1.2.X apps and one Rails 2.0RC1 app still in development.

Comments: 0 [add comment]

When working with Rails full time, it's easy to grow accustomed to the fact that when you do things right, other things "just work" without you doing anything else.

Case in point, I just got ready to see what I needed to do to make my RestfulCrudIntegrationTester work with nested routes. First thing to do was to write an Integration test using the plugin that tried to go to a nested route and see what errors I got. As I was half expecting, I didn't get any errors. I checked the test log, and sure enough, the controller reported that it got all the expected parameters and returned the correct page. So, here's what the routes and test look like, as a demo.

map.resources :posts do |users|
  users.resources :comments, :name_prefix => 'post_'
end
@post = Post.find(3)
new_session_as('me','super_duper_pass') do |me|
  me.reads_post_comments(@post)
end

And that's it. The resulting param hash at the comments controller is {"action"=>"index", "controller"=>"comments", "post_id"=>"3"} showing that the GET request went to '/posts/3/comments' as expected.

Tangent Alert

One note, you'll see that I used the :name_prefix option on the route above. My boss and I went back and forth on this for a while this week.

He was in favor of using it, as it makes your helper methods a little more descriptive (or so he claimed). With it, instead of comments_path(@post), you say post_comments_path(@post). My argument was that it's just as clear what comments_path(@post) does once you get used to it, it's less typing, and its convention over configuration (where adding :name_prefix to routes.rb would be extra configuration, overriding convention, and counter to the Rails philosophy). If we've learned anything this past year, it's that whenever you find yourself fighting the framework, you're doing something wrong.

This went on for a while, each of us steadily getting frustrated with the other's obstinance, and since we both work on the same code, it was imperative that we reach a consensus. "Agree to Disagree" was not an available option. One of was going to have to give in.

Then, out of the blue, he pulled a trump card out of Google. In Rails 2.0, adding the prefix onto the helper methods would be default behavior, and if you didn't want them, you'd need to add :name_prefix => nil in your routes to turn it off. Well, clearly, removing a few :name_prefix => 'something_' entries from the routes after upgrading would be a lot easier than searching through the code trying to find all the references to the helper methods and fixing those. So, adding :name_prefix now is just temporary configuration, in preparation for future convention.

In the end, I think we both won. He got his name prefixes, and I got my convention. And the point the story? Start using :name_prefix in your nested routes now, and save yourself some aspirin down the road.

Comments: 0 [add comment]

A project at the day job has me implementing some in pace editing. A quick search of the web found this page with a nice helper method that does all the hard work for me. Problem was, we're using RESTful routes and I was getting errors. Looking through the comments on the above linked blog post it was obvious I wasn't the only one having problems. Some more research and I think I've got it solved. Two options need to be added to the :ajax section of the options.

:ajax => {
  :ajaxOptions => "{ method: 'put' }",
  :paramName => "'my_model[my_field]'"
}

REST expects updates to be sent as a PUT, not a POST, which is what the browser wants to do by default, hence the necessity of the first option.

Next, paramName seems to be an undocumented option that I found only after digging through the Prototype source code. That changes the name of the text field in the form, so that it plays nicely with Rails apps. Obviousl,y you'll need to change 'my_model[my_field]' to the appropriate model and field names. Notice the nested double and single quotes... these are IMPORTANT!

With those two options added to the rest, it seems to work like a charm.

Comments: 2