RSpec an XHR Request
Looking at the RSpec docs it was not so obvious to me how you handled a XHR request in your controller specs, so here it is:
xhr :get, :index
Simple of course, just passing in the HTTP request type and the action you want requested to the xhr method. Still it is slightly confusing compared to the syntax for a regular get request which has it’s own get method:
get :index
For interests sake here is the code I was testing, it is an improved way of doing AJAX pagination with rails and jQuery than what is suggested here because using respond_to request.js when setting the request header to ‘text/javascript’ in jQuery like so doesn’t work reliably with all browsers.
The controller:
def index
@users = User.paginate(:order => 'name', :page => params[:page])
render(:partial => 'table', :layout => false) if request.xhr? # Otherwise render index.haml
end
And the spec for the xhr part:
describe "handling XHR /admin/users (for table AJAX pagination)" do
def do_xhr_get
xhr :get, :index
end
it "should be successful" do
do_xhr_get
response.should be_success
end
it "should render table partial template" do
do_xhr_get
response.should render_template('_table')
end
end
canberraruby.com - New Canberra Ruby Crew Site
I did a small amount of work on canberraruby.com just to get it off the ground. I explain it all there so please do take a look and if your in Canberra and would like to get involved with the ruby community why not jump on the mailing list and introduce yourself.
jQuery Toggler
I often like to have small form actions in my sidebar hidden away with javascript that are just a toggle away. Using jQuery to do this is quite easy but there are a few gotchas. Firstly we want both the always visible toggler link and a cancel button inside the toggled div to do the toggling. Next we want the first form input in the toggled div to become focused when we make it visible. It is important we don’t try and do this when we are toggling the div off (hiding it) as Internet Explorer will bork when you try and focus on a hidden element.
Starting with our HTML:
<div class="toggle">
<h2><a href="#new_category" class="toggler">Create New Category</a></h2>
<div class="togglable">
<form action="/" method="post">
<p>
<label for="category_name">Name: </label>
<input id="category_name" name="category[name]" size="20" type="text" />
</p>
<p>
<input id="category_submit" name="commit" type="submit" value="Create Category" />
or
<a href="#" class="toggler">Cancel</a>
</p>
</form>
</div>
</div>
Now the JS:
////
// Behaviours
$(document).ready(function() {
////
// Automatically hide all togglable elements on load
$('.togglable').hide();
////
// Toggle a .togglable div inside the clicked parent .toggle div
$('a.toggler').click(function() {
var togglable = $(this).parents('.toggle').children('.togglable')
togglable.toggle();
if(togglable.is(':visible')) {
togglable.find('input:visible:enabled:first').focus();
};
return false;
});
});
The sense in this is that I traverse up to the parent div ’.toggle’ before filtering down to ’.togglable’, this way I can click both the ‘h2 a’ and the ’.togglable a’ to get the same effect. Also then I make sure that I don’t try and focus on a hidden element because just doing ‘input:visible:enabled:first’ won’t check if any of it’s parents are hidden.
See the Demo Page.
BTW Google Hosted JS FTW!
Vote & Rails Camp
I didn’t have a blog at the time so I didn’t get a chance to pimp vote.rubyonrails.com.au so I am retrospectively doing so now :p. It was originally built to help decide the best date for the upcoming rails camp, but as it happened the results were not needed anyway. It was still fun to build and I got some great contributions from Pat and Matt which fixed some flaws and added some pretty graphs. I’m hoping now it can perhaps become a hack project for us to extend on at rails camp (which I’m really looking forward to now).
Checkout the source: http://rails-oceania.googlecode.com/svn/vote/
Rails, Ubuntu & ODBC
Whilst I cannot highly recommend the use of MS SQL Server with Rails it may be necessary in some situations for legacy integration and even then you have to carefully consider it’s usage (I’ll have more to say on this topic soon). Anyway when I first started to look into it I was told that connecting to a SQL Server via ODBC on Linux was both difficult and unreliable, but I found it to be neither. I have the instructions listed below for Ubuntu Gutsy and it will probably work on Hardy as well:
Start by installing the required packages (assuming you already have a Ruby and Rails stack installed):
sudo apt-get install unixODBC libdbd-odbc-ruby tdsodbc freetds-dev sqsh
Edit your ~/.bashrc file (assuming that you are just using the current user for the ODBC connection) and add the following to the bottom:
export ODBCINI=/home/<USER>/.odbc.ini
export ODBCSYSINI=/etc
export FREETDSCONF=/home/<USER>/.freetds.conf
Create ~/.freetds.conf and add the following:
# Compliments /etc/freetds/freetds.conf
[GLOBAL]
text size = 64512
[<YOUR_CHOSEN_SERVER_NAME>]
host = <SQL_SERVER_ADDRESS>
port = 1433
tds version = 8.0
nt domain = <NT_DOMAIN>
try server login = no
try domain login = yes
You can then test it out with sqsh:
sqsh -S <YOUR_CHOSEN_SERVER_NAME> -U "<NT_DOMAIN>\<USER>"
Now create ~/.odbc.ini and add the following:
[<DSN_NAME>]
Driver = FreeTDS
Description = ODBC connection via FreeTDS
Trace = No
Servername = <YOUR_CHOSEN_SERVER_NAME>
Database = <DEFAULT_DB>
Lastly we sudo edit /etc/odbcinst.ini and add the following:
[FreeTDS]
Description = TDS driver (Sybase/MS SQL)
Driver = /usr/lib/odbc/libtdsodbc.so
Setup = /usr/lib/odbc/libtdsS.so
CPTimeout =
CPReuse =
FileUsage = 1
Thats it but for one last tip, as of Rails 2 the SQL Server adapter is not included by default so I like to put it in my Rails vendor/plugins/adapters/sqlserver dir and that just works.