Helper Methods for render :update do |page|


@aneiro showed me this the other day and I just got it to work. So here’s what’s up.

Instead of having a metric crap-ton of rjs files I just started doing render :update do |page| in my controllers. This lets you do, as some people complain, javascript view logic in your controller. So I ended up with three actions that each call the same set of JS. Hide that thing, replace this div with a partial, show some stuff, fade some things, change the css class of that table row, etc…

So what you can do is this: define a method in your controller and put all the page.replace_html and page.hide calls in it. Do it. Ok so then in your render :update block you just call that method and pass page to it.

One caveat is you have to actually define your new method as a helper method, which is super easy. Just call, in your controller, helper_method .

Check out the gist:

Don’t leave this page cause I said so dialog


I have a process where I create an object on one screen, and then in the next screen add some information to that object.

Problem is, if you navigate away from that second page I have an object that has no important info attached to it.

My process is a wizard approach to setting up a new account, which only really has a name, and then the account has users and billing info attached to it in separate models/tables. So give it a name and save it, redirect to the next screen and add users and billing.

So I want the “Hey you! Don’t navigate away” dialog to appear on all but a few links and form submits on the add users and billing page. Its actually super easy.

Take a look at this very nicely formated gist
I would put this stuff in code tags and display it here but it looks like crap and I can’t embed gists unless I pay wordpress. And wordpress stripped all my erb and html tags so just go look at the gist.

Memcache Sessions in Rails

Linux, Rails, Ruby


Does rails scale? No! But memcached does!

Ok ok, you aren’t probably going to need memcache for caching huge queries yet.  But it is useful for storing your user’s session data server side and not having to worry about filling up cookies or clearing out files in your tmp directory or your database.

So I’ve been designing a single sign on system for the interanl applications at CI.  And I need apps on all kinds of different servers to talk to the same memcache instance(s) for their sessions.  I did follow this article on err.the_blog to get started but I only got so far and ran into some issues that got hard to debug.

The default memcached session store hits localhost:11211 which is generally fine for most applications but I needed a clustered approach and could not for the life of me figure it out.  Turns out like most things with rails it was really easy.

1. Memcached installed on your machine or whatever machine you want to use for sessions
1a. Top Funky has a really simple shell script that will work on os x and another that works on ubuntu
2. You will need the memcache-client gem, you know what to do.

In environment.rb in my rails app I needed to do a few things:

1. Setup the connection to the memcache server

2. Tell rails to use memcache for sessions

3. Setup rails to drop all its sessions stuff into the memcache server we setup

Alright so 1:
require 'memcache'
CACHE = => "your_app")
CACHE.servers = 'some_ip_address:some_port', 'another_ip_address_if_you_need_it:some_port'

and then 2(pretty easy)
config.action_controller.session_store = :mem_cache_store

and then 3 (this is where you can set the session timeout and then pass in the memcached object CACHE)

config.action_controller.session = {
:session_key => '_your_app_session',
:secret      => 'someotherkindofsecretthatnooneknows',
:cache       => CACHE,
:expires=>900  }

I think if memcache doesn’t find the session on one server it’ll look on the others you put in the CACHE.servers list.  However if your memcache instance goes down your rails app is hosed and starts throwing up 500 errors all over itself.

You can actually throw alot of this config into a gem if you are going to have several apps that are all going to use the same config (setup the CACHE stuff in your gem and then just do step 3 in your apps)  That way if you need to switch or add servers to your memcache setup you don’t have to make changes in 20 places.

Gmail with Rails…just so I don’t forget how to do it.

Rails, Ruby

Smtp settings in config/environment.rb:

ActionMailer::Base.smtp_settings = {
:address => “”,
:port => 587,
:domain => “”,
:authentication => :plain,
:user_name => “”,
:password => “*******”

Get code from this very helpful post.  Make the folders and files

  • action_mailer_tls
    • lib
      • smtp_tls.rb
    • init.rb

and copy/paste his code into the correct files you just created

LightMate Gedit Theme and now for TextMate too!

Design, Linux, Rails, Ruby

Ok kids, finally got the themes available up on my website:

Check the screenshot below for the gedit theme or hit up my website for screenshots of Textmate.

I really hate working in dark environments…well lights off yes, but a bright computing environment is a must. Thus when customizing gedit to work like TextMate for rails work I really hated the DarkMate theme – and the default lightish theme I didn’t like either.

So I made my own based on some colors from DarkMate. Take a look:

  • rhtml:

rhtml file

  • ruby:

ruby file

UPDATE: Theme is for GTKsourceview-2.0 and later (this is installed with Gutsy Gibbon). This theme will not work with Feisty or earlier releases.

download the theme here!

:disable_with kills form_remote_tag’s AJAXiness

Rails, Ruby

I had this awesome page. It had several forms on it – all pretty much the same thing – each form was a row of data parsed into form fields from a CSV file. So there were a lot of them (so the user can double check each item before committing the item to the db).

So I was using form_remote_tag to get the job done. Let me say now the tutorials out there are so outdated – they still use <%=form_remote_tag %>stuff<%=end_form_tag%> which has been deprecated for some time now. I finally figured out that its <%form_remote_tag %> (sans =) and then just <%end%>.

Great my remote form works.

Now I didn’t want the user to click the submit button twice (didn’t want duplicate objects in the db) so I did this: <%=submit_tag "add to db", :disable_with=>"adding to db" %>

I didn’t notice that after I added the :disable_with option my ajax request would die, and Rails being nice, sent the request as a regular POST request to the controller – thus the object is created but the page reloads – not fun when you have 80 items to add to the db.

I tore the entire form apart twice and finally today found that the :disable_with option kills the ajax request. I guess I’d have to use button_to with an onclick option that hides the button shows a disabled button and submits the request, but I’ll stick to just having a working ajax form with no fancy disabled buttons.