awkward silence

While on the subject of the new .rjs templates, Liquid is an optional templating system based on Django’s templates and implemented by Tobi of Typo fame. I haven’t tried them yet – this is a sort of ‘note to self’ to give them a whirl one of these days. .rhtml is great, but it’s nice to have options.

“Marcel Molina Jr. recently announced that RJS templates would not be included in the 1.0 release of Rails, but that they might include them as a plugin.

I thought that it was about time for me to learn the plugin system in Rails anyway, so I packaged up all of Sam Stephenson’s hard work on the RJS templates from changesets 3078 and 3084 and turned it into a plugin.”

Rails RJS Templates Plugin

Since it was announced that the new .rjs templates wouldn’t be shipping with Rails 1.0, Cody Fauser went ahead and packaged them up as a plugin. You can use the plugin with the rails stable trunk or the 0.14.3 gem.

.rjs templates are well worth looking into if you do any ajax in your views. Thanks Cody!

I got a bad case of code formatting envy when I saw Cody’s post on .rjs templates. I’ve been happily running a somewhat dated Typo install since it basically worked, but when I read about the new (to me anyway) Macros, I knew it was time to make the leap.

In the past I’ve downloaded the source to my local machine, done whatever config there is, then uploaded the final pieces to my account. This time I thought I’d try the direct route. I made a backup of my typo directory and database, then did a svn checkout directly to my web account:

svn checkout svn://leetsoft.com/typo/trunk typo

I cd’d into the new typo directory and ran

rake migrate

But got these nasty errors.

So I panicked for a minute. DreamHost has upgraded to Rails 0.14.3, which is great, but I needed something newer, fresher, edgier. So I moved to my typo/vendor directory and

svn co http://dev.rubyonrails.org/svn/rails/trunk rails

And that was it! I ran migrate again and it worked like a charm. Now I have Trunk Typo on Edge Rails and it’s working great.

This is cool. Just when you think those Rails guys are about out of tricks, they pull this out of their hat.

If you’ve used the groovy AJAX tools in Rails much, you’ve probably hit the point where you have to update two elements on a screen. It gets ugly pretty quick, with calls to “evaluateremoteresponse” and “updateelementfunction” (as best I recall) and it really gets to be unclear what is doing what to whom and when.

RJS to the Rescue!

Here’s a little addition/clarification to the demo that Cody posted.

In a controller, add these:

def fox
  @header = "A Nice List of Animals"
end

def add
  @new_item = params[:arg]
  @header = "All Your List Are Belong To Us!"
end

def remove
end

Your fox.rhtml would look something like:

<h1 id='header'><%= @header %></h1>
<ul id='list'>
  <li id='dog'>Dog</li>
  <li id='cat'>Cat</li>
  <li id='mouse'>Mouse</li>
</ul>
<div><%= link_to_remote("Add a Fox!",
      :url =>{ :action => :add, :arg => "Fox" }) %></div>
<div><%= link_to_remote("Nuke the Cat!",
      :url =>{ :action => :remove }) %></div>

Your add.rjs goes in your views directory next to the other views for that controller:

page.insert_html :bottom, 'list', content_tag("li", @new_item)
page.visual_effect :highlight, 'list', :duration => 3
page.replace_html 'header', @header

And also toss in a remove.rjs for fun:

page.visual_effect :shrink, 'cat', :duration => 1

And Voila! This is still a simple example, but you can see that it will sure help clean up Ajax-driven pages a whole lot.

If you’re having trouble connecting this snippet may help. This is handy as it runs in isolation from the rest of your Rails application which can be very useful in debugging.

Change the name of the class to be one of your table names (singular).

require ‘rubygems’
require ‘active_record’

If you connect you won’t see any errors. Otherwise you should get an error that has some useful info.

I spent an evening trying to figure out why my RAILS_ROOT environment variable was out of whack the other night. It turns out that it is set relative to where you launch WEBrick from.

Usually I launch WEBrick from the root of my application:

>ruby script/server

For some reason, the other night I thought it would be handy to open my command window right in the script directory. I could then just use:

>ruby server

But then I got errors which turned out to be caused by RAILS_ROOT being set wrong which throws everything out the window.

I did get the chance to use the console to debug though, which just reinforced how cool that guy is. Just fire up:

>ruby script/console

And at the prompt, type:

RAILS_ROOT

And low and behold, the value is there to see.

It turned out I figured out the issue when I fired up WEBrick the next night from my usual location and everything just worked again.

There are a couple of reasons that you may want to do this. One is to be master of your universe. I really like this and will be moving Clubrs to use that.

You may also find a gem that your web host doesn’t have installed. You can ask them to install it, and they might, but you can also use it without their intervention. Here’s all you have to do:

1. Install the Gem on your own system
2. Open a command window in [RAILS_HOME]/vendor
3. Type ‘gem unpack gem_name’ to expand the gem

4. UPDATE: Use the path to the lib folder in your require, e.g.:

   require ‘units/lib/units’

That’s it. Now your app will have access to the gem as normal. Also, if there’s an installed version of the gem, your app will use your expanded gem rather than the installed gem.

The Rails team put in a nice, related feature with the 1.0 release candidates. There’s a Rake target to ‘freeze’ rails to a particular version:

rake freeze_rails

That will give you all the core Rails gems unpacked to

vendor/rails

To reverse you can use

rake unfreeze_rails

Which simply deletes the /vender/rails directory.

So the Google Web Accelerator is back and twice as lethal as before….

More interesting for most applications, especially those already requiring Javascript to do Ajax, is the addition of :post => true to link_to.
This will add a onclick attribute on the ahref, which generates a
dynamic, invisible form that again turns the GET into a POST.

How Rails is prepared for GWA II: Vengeance (Loud Thinking)

It’s nice to use a framework that handles the issue at all, let alone with a couple of elegant solutions. If you have any links (href=) in your app that alter the state of your database (deletes, especially) be sure to read up on this.

Rails makes doing the right things easy and the wrong things a bit more difficult. One of those right things is testing, and the Rails 1.0 release candidate has a new set of defaults and a couple new goodies to help your tests go faster. And when tests go faster, they tend to get run more often.

Mike Clark’s Weblog

If you have any tests that are failing after upgrading, this may be why. It’s a nice article covering not only what has changed, but why.

I’m trying the new browser, Flock, with a built-in blogger. To set it up for typo, follow their instructions to add a blog. (Tools -> Options -> Blogging) I found that I had to enter a URL that failed (try the rss feed of your blog). When Flock complains, click Cancel. Then you get to the screen where you can enter your info (I couldn’t figure out how to get there more easily):

XML-RPC API: Moveable Type
Blog ID: Whatever you want to call it
Access Point: http://yourdomain.com/backend/xmlrpc

That should get you started. Then click the feather icon in the toolbar of Flock to get the window. It looks pretty promising (I had to post this to try it out). Click the ‘TOPBAR’ button to get a list of your posts. There’s a sort of well that says ‘Drag stuff here to blog it!’. I need to try that next…

To download Flock, you need to go here:

Log in here:
http://www.flock.com/developer/download/preview/
  username: caveat
  password: emptor