I’ve been discovering the excellent ‘behaviour-driven development’ plugin ‘rspec’ , and its rails-specific cousin (nephew?) ‘rspec_on_rails’ this week.

At the moment i’m testing that validation works properly on some models. Now, rspec already generates a matcher for any predicate method that can be called on an object (eg “object.should be_foo” for “object.foo?.should eql(true)”). I was using this with valid?, which we use on an typical (ie ActiveRecord) model to see if it will pass validation (and therefore be able to be saved to the database). This is generally nicer than trying to save it and seeing if it saved ok.

So, i was writing specs like this

it "should validate with only a name" do
  @foo = Foo.new(:name => "bar")
  @foo.should be_valid
end

This works, in terms of correctly passing or failing, but it doesn’t give me much information – it just tells me that something fails validation. I could get at the error messages in the test by doing the test as follows:

it "should validate with only a name" do
  @foo = Foo.new(:name => "bar")
  @foo.should be_valid
  @foo.errors.full_messages.should eql([])
end

but this is a bit tiresome. I’d rather just write “should be_valid”. So, i decided to write a custom matcher that overrides the auto-generated ‘be_valid’ method and tells me why it failed validation (if it does fail). Here’s how i did it. Thanks to the excellent peepcode rspec movies for the inspiration and knowhow!In my spec folder, i made a file called ‘custom_matcher.rb’. In it is a module which will hold any custom rspec matchers i write, though there’s only one at the moment.

module CustomMatchers
  #checks that an AR model validates, by testing error messages from .valid?
  #displays any error messages recieved in test failure output
  class BeValid
    #do any setup required - at the very least, set some instance variables.
    #In this case, i don't take any arguments - it simply either passes or fails.
    def initialize
      @expected = []
    end

    #perform the actual match - 'target' is the thing being tested
    def matches?(target)
      #target.errors.full_messages is an array of error messages produced by the valid? method
      #if valid? is true, it will be empty
      target.valid?
      @errors = target.errors.full_messages
      @errors.eql?(@expected)
    end

    #displayed when 'should' fails
    def failure_message
      "validation failed with #{@errors.inspect}, expected no validation errors"
    end

    #displayed when 'should_not' fails
    def negative_failure_message
      "validation succeeded, expected one or more validation errors"
    end

    #displayed in the spec description if the user doesn't provide one (ie if they just write 'it do' for the spec header)
    def description
      "validate successfully"
    end

    # Returns string representation of the object being tested
    def to_s(value)
      "#{@errors.inspect}"
    end
  end

  # the matcher method that the user calls in their specs
  def be_valid
    BeValid.new
  end
end
#To hook it up, add the following require to spec_helper.rb:
require 'spec/custom_matchers'
#And add the following line to the "Spec::Runner.configure do |config|" section:
config.include(CustomMatchers)

This is about as simple as a matcher could be – i don’t take any arguments at all, so the expected result is always an empty array (of errors). The ‘value’ added by this is that i’m now outputting the error messages (if any) in the failure report. Because i’ve provided a description method, i don’t even need to provide a description to my specs if i don’t want to: for example, here’s a test which will fail (and its surrounding description):

describe SchoolSubscriber, ", when we make an empty school_subscriber, " do
  before do
    @ss = SchoolSubscriber.new
  end

  it do
    @ss.should be_valid
  end
end

And here’s the failure report from rspec:

1)
'SchoolSubscriber , when we make an empty school_subscriber,  should validate successfully' FAILED
validation failed with ["Phone number can't be blank", "First name can't be blank", "Position can't be blank", "School can't be blank", "Last name can't be blank", "Email can't be blank"], expected no validation errors

Sometimes a table gets messed up and the best thing to do is to wipe it and recreate it from scratch.  Also sometimes, we don’t have a rake migration for it, or it was built up through a series of messy migrations that add bits, remove them, add other stuff, etc.

If we delete all the rows, we DON’T always get the same as an empty table – if, like in most rails tables, we have a primary index (usually id) which is set to autoincrement, if we delete all the records and then add one, the first row won’t be numbered 1, it will be numbered after the last row to be created.  So, we’re not really starting from scratch.

A nice quick way to just recreate a blank version of the table from scratch is as follows.

1) Make an sql dump of the entire database:  at the command line, type

rake db:structure:dump

2) This will create an sql script file called development_structure.sql in the db folder, which contains instructions for adding all of the tables to the db.  Open it in a text viewer and look for the section concerning the table you want.  Copy it out.

3) Lose the existing table – at the sql command line type “drop table your_table_name”

4) In a sql browser, or at the command line, paste in the section of sql script from the dump and run it.

Voila – nice empty table, with indexes all starting from scratch.

5) If you have any migrations to populate the table with data, you can copy the code out of the ‘up’ method, run a rails console, paste in the code and run it.

Let’s say that i have a table called Person, with a corresponding database table ‘people’, that already has a lot of records in it. It so happens that in my app men and women have slightly different rules associated with them, and are often searched seperately (eg search boxes have a ‘only search women’ checkbox).

The database represents gender by a field called ‘male’, which holds a boolean: men are ‘true’ and women are ‘false’. (this seems a bit sexist, but it ensures that there are only two possible values).

I’m sick of typing

:condition => ["male = ?", person.male]

all the time, and i’m generally sick of dealing with Person when there really should be two seperate classes which are dealt with differently. I want instead to be able to deal with Man and Woman, eg to sayMan.find(:all) etc, but i don’t want to start making serious changes to the database schema.

We can fix this with single table inheritance. This has two stages: 1) alter the database, and 2) extend Person into two new classes.

Stage 1 – we create a new string field in the ‘people’ table called ‘type’. This is simple with a database migration: at the command line (making sure we’re inside our project directory), type

ruby script/generate migration add_type_to_people

This should create a migration with that name.

Now, this migration has to do a bit more work than usual. We’re adding a new column, but we need to populate it as well, with either “Man” or “Woman”, which we don’t normally do in migrations. There’s nothing magical happening in migrations – we can put any rails command in there and it will get executed when the migration is run. In this case, we want to do an SQL update on all the records, and change the value in ‘type’ depending on the value of ‘male’. As it happens there’s a nice rails helper for this, called ‘update_all’. This allows us to enter the new value and an optional condition, without having to use SQL.

Looking at the ‘male’ field, we see that it happens to default to true (Come and see the sexism inherent in the system! Joking aside, if you’re going to default a boolean field, always default it to 0 (false) so that NULL and false are sort of equivalent.  Anyway lets assume that whoever set this table up hadn’t had their morning coffee yet). That means that while a woman has ‘male = false’, a man might have ‘male = NULL’. With our calls to update_all, we should follow this logic, and first set all of the values of ‘type’ to ‘Man’, then set it to ‘Woman’ where ‘male = false’. So the calls to update_all will be -

Person.update_all(‘type = “Man”‘)

(note the quotes here – single around the whole argument, double around the string “Man”)

Person.update_all(‘type = “Woman”‘, ‘male = 0′)

Note that we compare male against ’0′, not ‘false’. This is because the database (well mysql at least) stores bools as 0 and 1 values in a ‘tinyint’ field.

So, here’s the whole migration:

class AddTypeToPeople < ActiveRecord::Migration
def self.up
add_column :people, :type, :string
Person.update_all(‘type = “Man”‘)
Person.update_all(‘type = “Woman”‘, ‘male = 0′)
end

def self.down
remove_column :people, :type
end
end

Then run it with (at the command line)
rake db:migrate

That should be it for stage 1. We can check by looking in the database, either using a gui (such as heidisql) or an sql request like

select male, type from dbname.people

which will show us only the male and type columns, which we can look down to see that the values match up properly.

Stage 2 – This is easier – first we need to add two new models, Man and Woman, which extend Person. Super simple.

in app/models/man.rb

class Man < Person
end

in app/models/woman.rb

class Woman < Person
end

That’s it! We can now call methods on Man and Woman as we would on Person.

Actually, we’re not quite out of the woods yet – what happens when a new person is added to the database, or when someone whose gender was left blank is updated to be female? (ie male = false) We need to do a callback, that calls a method to correctly set the value of ‘type’ whenever a record is updated or created. For our purposes, before_save is fine.

So, in person.rb -

class Person < ActiveRecord::Base

#will be triggered when saving a new or updated object
before_save :set_type

#and now the method that the callback calls. Remember that male
#defaults (bizarrely) to ‘true’

def set_type
if self.male == false
self.type = “Woman”
else
self.type = “Man”
end
end

#or, for those who like conditional expressions -
def set_type
self.type = (self.male == false ? “Woman” : “Man”)
end



end

This should keep our database in line.

Thanks to rubyphunk from railsforum.com for giving me a lot of help with this. For anyone reading, i’m assuming you’ve got a basic understanding of rails already.

I’m learning ajax and restful rails at the moment, which is a hard thing to do because they both involve routing, and both have great power to confuse (me at least). So, here’s how i do a table of records which uses ajax to refresh the table when a record is deleted. I also show a way (possibly not the best way) to do a table with alternately coloured columns.

This is written in rails 1.2.5, aka ‘Rails 2.0′, but if you’re using an earlier version it should still work, provided you use the right scaffold (i’ll explain later).

Anyway, let’s get on with it – to learn about ajax and restful rails we’re going to make an app from scratch. The app is going to be super-simple – it’s a blog app which has one model, ‘Entry’ (don’t ever call a model ‘Post’ when doing restful rails. You’ll hurt your brain. Trust me) , which has a title and body field, along with the usual created and and added at timestamps. The index page will show a table of blogs, with just the start of the title and body shown, along with timestamps, and an edit and delete option – all the usual simple scaffoldy stuff.

The ajax will be used only with the delete command – when someone deletes a post, we want the table to update withoout reloading the page. To check that the page hasn’t refreshed, we’re going to put the current time on the page, which will only be updated when the page has reloaded. So, if we see the table update without the time changing, we’ve succeeded. Oh, and we’re also going to give the table vertical stripes, for no other reason than i was curious about how to do that. Let’s go.

in your rails app directory:

rails ajaxblog
cd ajaxblog

now, let’s go in and make the scaffold for our single model, ‘Entry’. This has a ‘title’ which is a string, and a ‘body’ which is text (long string). Don’t worry about the timestamp fields for now.

ruby script/generate scaffold_resource entry title:string body:text

(if you’re using rails 1.2.5, ‘scaffold_resource’ won’t be recognised. Just use “scaffold” instead. scaffold_resource is the old restful scaffold, which has now become the standard in 1.2.5 onwards. I specified that here because it’s better to put in the wrong one and get a complaint, than to put in the wrong one and just get the wrong kind of scaffold made)

Now, rails has kindly generated a migration for us, so lets make a database for it to use:

mysqladmin -u root create ajaxblog_development

This is the default name specified in config/database.yml, so that’s all we need to do.

Now, go and look at the migration in db/migrate – 001_create_entries.rb:

class CreateEntries < ActiveRecord::Migration
def self.up
create_table :entries do |t|
t.string :title
t.text :body

t.timestamps
end
end

def self.down
drop_table :entries
end
end

We can see that because we told the scaffold about ‘title’ and ‘body’, it’s set up the migration for us with those fields specified. It also provides requests timestamps (updated_at and created_at) by default. So, we don’t need to do anything with the migration. I just wanted to show you something nice :)

So, close the migration without making any changes, and run

rake db:migrate

Cool. So, we should have a restful blog app now. Start a server (“mongrel_rails start” or your equivalent), go to the address specified (eg http://localhost:3000) and you should see the rails start page. Add “/entries” to the end of the url, and you should see a page with a table for entries.

So, have a play around with that. Notice that the urls are different from traditional rails – for example, the page with the list of entries would normally have been associated with an action called ‘list’ (or similar) in EntryController, and therefore have a url of /entry/list. Now it’s just /entries, which automatically calls the action “index”, which is used to provide a list of entries. This is how rest works – the urls are kept as simple and as standardised as possible, and we tell actions apart based (with some exceptions) on the type of http request rather than the method names in the controller.

Use the interface to add an entry, and you’ll be taken to the ‘show’ page for the new entry. Before, the url would have been something like /entry/show/1. Now it’s simply /entries/1. So, again, we’ve missed out the action name, but the app knows what to do because when we requested the show action, we sent, via the browser, a GET request, and GET requests, when combined with a url of /entries/1, are associated with the show action. I’m not going to go into REST in too much detail here, there’s plenty of other stuff out there.

To illustrate this, let’s make our first change to the scaffold code. When someone adds their entry, we want to go straight back to the index page, to see it on the table. So, we need to edit the create action, which adds the new entry (using info from the form on the ‘new’ page) to the database.

In entries_controller.rb, in the create action, we have

# POST /entries
# POST /entries.xml
def create
@entry = Entry.new(params[:entry])

respond_to do |format|
if @entry.save
flash[:notice] = ‘Entry was successfully created.’
format.html { redirect_to(@entry) }
format.xml { render :xml => @entry, :status => :created, :location => @entry }
else
format.html { render :action => “new” }
format.xml { render :xml => @entry.errors, :status => :unprocessable_entity }
end
end
end

The respond_to block might look a bit alien – don’t worry about it for now. We’re only going to edit this line -
format.html { redirect_to(@entry) }

This is called when the record is successfully added and html is requested, which is the default file type – ie, we’re only worrying about which html page we get sent to next. Change this line to be
format.html { redirect_to entries_path }

entries_path is a helper which basically remembers the url “/entries” for us. This should take us to index after we submit a new post.

Next task – make a nicer table. In particular, lets have one that shows the created_at and updated_at data, has fixed width columns, and also has alternately coloured columns, so we can tell them apart easier.

The table is going to have two sections – the header row, where we choose names for each column, and also specify the widths, and then the record rows, which we’ll build with a for loop in the usual rails way (“for entry in @entries”, etc) . Now, the code to populate each column is going to be quite varied, because we’re not going to simply displaying the raw data. Text needs to be truncated to fit into the table, and we want our time stamps to have the format “about 1 hour ago, 2 days ago, etc”. So, we’re going to put all of this ruby code into a helper, which we call in the view. Clean views are good!

In addition, to keep things even cleaner (and to help with the ajax later) we’re going to put the table into a partial, passing through @entries as a local variable (entries, without the @) for the partial to use to populate the table.

So, edit the app/views/entries/index.rhtml (might be html.erb if you’re using the latest rails) view to look like this:

<h1>Listing entries</h1>

<%= link_to ‘New entry’, new_entry_path %>
<hr/>

<div id=”entry_table”>
<%= render :partial => “entries”, :locals => {:entries => @entries} %>
</div>
<hr/>
<%= link_to ‘New entry’, new_entry_path %>

This is all pretty standard stuff, except for the “New entry” link. Whereas previously we’d have specified an action, eg :action => “new”, we now just pass along the path helper, in this case “new_entry_path”. This is just another way to standardise things, and increase our DRYness. We don’t have to worry about the new method being renamed to “add” or something – in fact we don’t even see what the method is called, though it should be called ‘new’.

Anyway, this references a partial for the table, so lets make a new partial view for the table: “/app/views/entries/_entries.rhtml” (or html.erb) :
<table border=”0″ cellspacing=”0″>
<tr font-weight=”bold”>
<% column_names.each do |width, name| %>
<td width=”<%= width %>%” class=”<%= cycle(‘table-column-header-odd’,
‘table-column-header-even’, :name => “stripes”) %>”> <%= name %> </td>
<% end %>
<% reset_cycle(“stripes”) %>
</tr>

<% for entry in entries %>
<tr>
<%# use the column_data helper to get the code for the cells %>
<% column_data(entry).each do |cell| %>
<td class=”<%= cycle(‘table-column-odd’, ‘table-column-even’,
:name => “stripes”) %>”> <%= cell %> </td>
<% end %>
<% reset_cycle(“stripes”) %>
</tr>
<% end %>
</table>

This builds the table with the use of helpers, as mentioned earlier. The reason for this is two-fold:

  • There’s a lot of ruby code to populate the columns with correctly formatted data. Try to avoid filling up your views with ruby code, as it scares web designers, who we want to feel relaxed (and therefore creative) when they prettify our pages. Much nicer to hide it away inside a helper.
  • To achieve a striped columns effect, i’m using a rails helper called ‘cycle’, which simply cycles between a set of objects it’s given, whenever it’s called. (i don’t know how it keeps track of which one it did last…some magic). In this case, the objects it’s cycling between are some strings, which happen to be the names of styles in my stylesheet (i’ll get to those soon). Each style simply specifies a different background colour. As you can see, the call to ‘cycle’ is a bit cumbersome, and if i had it before every <td> element in a row the view would get spectacularly ugly very quickly. So, instead, i iterate through the an array of chunks of code, which is what the helper provides, and only have to write the cycle call out twice – once for the header row, and once for the record rows. Note with ‘cycle’ that you want to reset it at the end of each row, otherwise if you have an odd number of columns you’ll get a checkerboard effect. That’s why we name the cycle, so we can pass the name to the reset_cycle helper.

So, here’s the helpers used to populate the table: they live in app/helper/entries_helper.rb, which scaffold has kindly provided you with. First, the one to do the header row. This returns an array of arrays, with each subarray holding the width of the column (in percent) and its title.

#returns the width and names of the columns
def column_names
[[28, "Title"],
[28, "Body"],
[17, "Created"],
[17, "Updated"],
[5, " "], #create a column for ‘edit’
[5, " "] ] #create column for ‘delete’
end

Then, back in the partial, i call this method, get the array, and iterate through, passing the members of the subarray through as local variables to be substituted into td attributes.

column_names.each do |width, name|

The other partial works in the same way, except that there’s no subarrays – it’s just a simple array of pieces of ruby code, all bracketed up to avoid confusion. The partial takes the array, and iterates through it to get each bit of code to use to populate the relevant column. I’ll print it in full and then go through line by line, since there’s some restful stuff happening.

# Returns the pieces of code used to populate the entries index table columns
def column_data(obj)
[(link_to truncate((h obj.title), 35), obj),
(truncate((h obj.body), 35)),
(“#{time_ago_in_words(obj.created_at)} ago”),
(“#{time_ago_in_words(obj.updated_at)} ago”),
(link_to ‘Edit’, edit_entry_path(obj)),
(link_to ‘Delete’, entry_path(obj), :method => :delete ) ]
end

Now lets break this down line by line.

def column_data(obj)
‘obj’ is the object passed through from the partial – in this case, an ‘Entry’ object, from the “for entry in entries” line in the partial. So, whenever we see ‘obj’ it’s as if we’re saying ‘entry’. I know that seems obvious but some of the rest calls might be a bit unfamiliar and it’s easier to understand if you mentally substitute ‘entry’ in there.

[(link_to truncate((h obj.title), 35), obj),
link_to tells us this is a link – in this case, if someone clicks on the title i want them to be taken to the ‘show’ page for that entry. All that’s required for ‘show’ is to pass through the object to be shown – rails assumes that it’s an entry since we don’t ask for a specific path.

truncate simply truncates the text to the specified number of chars and puts an ellipsis “…” at the end.

We say (h obj.title) instead of simply (obj.title) as a security measure. h is a helper which treats text as raw text, rather than trying to use it as html, which the browser might otherwise try to do. This is a simple security measure – it means that if (for example) someone enters a ton of javascript as their blog post in order to hack our site, then all that happens is that they have a blog post full of javascript code – it doesn’t run it. At least, that’s my understanding of it :)
(truncate((h obj.body), 35)),
(“#{time_ago_in_words(obj.created_at)} ago”),
(“#{time_ago_in_words(obj.updated_at)} ago”),

These are all pretty simple – time_ago_in_words is just another helper for formatting a time value into text such as “about 1 hour”. You need to add ” ago” yourself at the end for the desired effect in this case.

(link_to ‘Edit’, edit_entry_path(obj)),
Again, rather than passsng :action => “edit”, :id => obj, as we would in traditional rails, here was just call the relevant path helper with the desired object.

(link_to ‘Delete’, entry_path(obj), :method => :delete ) ]
This is more RESTful stuff – notice the “:method => :delete” at the end? This tells the browser to send a DELETE request (well, actually a pseudo-delete request since browsers aren’t allowed to send delete requests. Rails understands :) For the purposes of *our* understanding of REST, think of it as an http DELETE request. When the controller gets a delete request, and is given the path to an object (which will equate to /entries/obj_id), then it calls the ‘destroy’ action on that object, in the relevant controller – entry_controller in this case, since we give it ‘entry_path’. The scaffold provided us with a perfectly working destroy action in our controller, so we don’t need to worry about it any more (for now).

end

Finally, before i forget, let’s get the styles in there. Make a new stylesheet in /public/stylesheets called ‘ajaxblog.css’, and put the following styles into it -

.table-column-even {
background: #f0f0f0;
}

.table-column-odd {
background: #f8f8f8;
}

.table-column-header-even {
font-weight: bold;
background: #f0f0f0;
}

.table-column-header-odd {
font-weight: bold;
background: #f8f8f8;
}

(i know next to nothing about stylesheets, and i think this isn’t the official way to set them up. But hey ho it works.)

And of course, we need to make sure that our layout knows about the new stylesheet. So, go and open app/views/layouts/entries.rhtml, and add this line in the head element, next to the scaffold stylesheet reference -

<%= stylesheet_link_tag “ajaxblog”, :media => “all” %>

While you’re there, add this line as well, below the css references in the head. We’ll need this for our ajax later but since we’re here now we might as well -

<%= javascript_include_tag :defaults %>

OK! That was quite a lot of stuff to do in a single iteration, so go and check that it all looks ok. Table nice and stripy? (you can change the colours in the stylesheet). Delete and edit work? Adding a new entry takes you back to the index? Good.

So, now that we’ve got our restful app working, let’s do some ajax. We’re going to be changing the functionality of ‘delete’, so that it just updates the table, rather than reloads the page. But how can we tell the difference? It’s hard in this case, with such a simple app, because the page will tend to reload so quickly that we might not even see it happen. So, let’s add the time to the page – that way, if the page is reloaded, the time will change. (this might not be the best demo of ajax but it sure is simple)

In app/views/entries/index.rhtml, add the following, below the <h1> line -

<span>Current time: <%= Time.now.strftime(“%H:%M:%S”) %> </span>
<br/><br/>

This just shows the local system time in 12:34:56 format. Try refreshing the browser a few times to check it works. So, we want to update the table without changing this value. Let’s (FINALLY) do some ajax.

First thing to do is to change what happens when the user clicks on the ‘delete’ link. We need to change it to make a remote ajax call. This involves replacing the link_to helper with another helper, called “link_to_remote”. Here’s the old line which, remember, is hidden away in entries_helper.rb:

link_to ‘Delete’, entry_path(obj), :method => :delete

And here’s the new one -

link_to_remote ‘delete’, :url => entry_path(obj), :method => :delete

As you can see, it’s not radically different. Instead of passing entry_path, we point :url at entry_path. But the link_to_remote means that we’ve got an ajax call happening.

Next, we need to go and look at the destroy method in entries_controller, which is called by a DELETE request on an entry object, remember. This is what it looks like at the moment:

# DELETE /entries/1
# DELETE /entries/1.xml
def destroy
@entry = Entry.find(params[:id])
@entry.destroy

respond_to do |format|
format.html { redirect_to(entries_url) }
format.xml { head :ok }
end
end

If you’re new to REST, this will look quite unfamilar once we get to the “respond_to” line. I’ll get to that in a minute.

First, we need to change the controller to provide an updated value for @entries, which we’re going to pass through to the updated table in a minute. So, after the line that destroys @entry, we update @entries:

@entries = Entry.find(:all)

Now, the respond_to block – what’s happening here is that we specify what data we can supply in response to various formats of request. I’m not getting into the xml here – let’s just worry about the normal case, when html is requested. What the controller would do in that case is call the format.html line, which has a block of code that simply redirects back to the index page, ie reloads the page.

If we got an ajax request, we don’t want to redirect – we’re planning on reloading just the table. So we need to stop it from redirecting if we got an ajax request. The way to do this is simple – change the line as follows:

format.html { redirect_to(entries_url) unless request.xhr? }

Our final change is to make sure that when we fall out the bottom of the controller (as we will do now that we no longer redirect anywhere), rails looks for some javascript to run. (at least, that’s my understanding, i could be wrong). So, at the bottom of the list of formats, just add

format.js

So, our new destroy action looks like this:
# DELETE /entries/1
# DELETE /entries/1.xml
def destroy
@entry = Entry.find(params[:id])
@entry.destroy
@entries = Entry.find(:all)

respond_to do |format|
format.html { redirect_to(entries_url) unless request.xhr? }
format.xml { head :ok }
format.js
end
end

The “request.xhr?” part will return true if the action was called by an ajax request. In this case, if the request isn’t an ajax request, we deal with updating the table the old fashioned way – by simply reloading the whole page with a redirect_to call.  Putting this test, using request.xhr?,  into our ajaxy actions is a good habit to get into, as it allows you to deal with the case where the user doesn’t have javascript enabled in their browser, and to do it another way.  This is a good reason, when planning on writing some ajax, to get the functionality working first using the old-fashioned page reloading.  That way, it’s easy to fall back onto the non-ajax functionality if the user can’t, or doesn’t want to, use javascript.

However, if it is an ajax call, then nothing happens, and we just drop out of the bottom of the method. Now what?

This is where the really clever stuff comes in. Rails has a load of javascript helpers that help us to use ajax without actually using the required javascript. They go into rjs (ruby javascript) files, that live in the view folder corresponding to the controller holding the action, and are named the same as the action. An, because we added format.js to the bottom of the respond_to block in the controller, when we fall out the bottom of the controller method rails will look for an rjs file called “destroy.rjs”.

So, in /app/views/entries, create a new file called “destroy.rjs”, and add to it the following line:

page.replace_html ‘entry_table’, :partial => “entries”, :locals => {:entries => @entries}

Let’s see what’s going on here -

  • “page” is an object provided to us by rails to work on. It corresponds to a page of html, from which we pull out individual components, identified by their “id” attribute.
  • replace_html is one of those nice javascript helpers i mentioned. It replaces the element with the id that follows (“entry_table”, which is what we labelled the div that surrounds the call to the table partial, in index.rhtml)
  • So, what do we replace it with? We replace it with a partial, by specifying :partial. Generally i believe it’s the common practise to use ajax to replace a whole partial rather than bits and bobs here and there. It might even be essential (i’m new to this myself and not sure). The partial is of course “entries”, which contains the table. So, we’re saying ‘replace the table with an updated version of the table’.
  • Finally, we pass through to the partial the same parameters that we passed through when we call it from the index page: “:locals => {:entries => @entries}”. In this case, @entries has been updated by the ‘destroy’ method in the controller, and now no longer contains the record we just deleted.

The end result of all this is that the partial with the table gets reloaded, with a new value of @entries to dutifully iterate through, and we see our deleted record disappear, without the page being reloaded (make sure the time doesn’t change!).

So there you go. Add ajax and RESTful rails to your skills list and go and make a celebratory cup of tea. Of course, i’ve barely grazed the iceberg of ajax or REST here, so go and read some more about both of them while you drink it.

Submission day tomorrow!

September 23, 2007

I’ve been too busy to write any new blogs.  Even the one i posted earlier today had been sitting on my laptop for nearly a week and a half till i got round to hitting the ‘submit’ button.  Tomorrow is deadline day, so i’m finishing off a few bits and pieces.

Going on holiday for a few days afterwards, can’t wait. :)

I can see the head!

September 23, 2007

If a rails app were a baby, the pregnancy would be wonderful and the labour would be a horrible, painful affair with the blood, and the screaming, and the fainting nurses, and the obstetricians working shifts. I’m at the stage now where the head is mostly out, but those wide shoulders are causing everyone a lot of trouble.

What i’m trying to say is – it’s up! At www.reeplies.com. I’ll fix the route for this later so reeplies.com works, but for now it’s best hidden away as it’s pretty broken – basically, gems don’t work. I can’t *install* my own gems on the server – this would be the ideal way. What i need to do is to ‘freeze’ them into local files (that live in the vendors folder) and then copy those files over.

For now, you can add articles, as long as you put the title in (i commented out the bit where reeplies says you can leave title blank). However, if you try and *view* an article, the code breaks because it needs the rmagick gem to show pictures.

Yesterday, James McCarthy gave me way too much of his time trying to get the deployment working. We were having all sorts of problems, with not very much (if any) feedback about what the problems were. The app was just broken. No trace or nothing. In the end, i built up a new app from scratch, following bluehost’s instructions, then made the structure the same as mine (with ./script/generate controller article etc for every controller and model), then replaced all the empty files with my app’s files, doing the same thing for the public folder. And that works, except for like i say, the gems are missing.

Still though, feel massively buoyed by the fact that the damn thing is working in a limited way. I’m confident i can solve the gems problem as well, with james’ help and some forum action – lots of people must have had this exact problem before.

I already tried getting a tar file (destined for *nix surely), copying it over the the app vendor folder via ftp, then untarring it on the server, via ssh – this seemed to work, in that it untarred to the correct place, but the app still crashes.

Next step -after following a tutorial on the bluehost site, i changed my .bashrc file, which lives in the root directory of my allocated folder, by adding the following:

export PATH=”$PATH:$HOME/packages/bin:$HOME/.gems/bin”
export GEM_HOME=”$HOME/.gems”
export GEM_PATH=”$GEM_HOME:/usr/lib/ruby/gems/1.8″

export GEM_CACHE=”$GEM_HOME/cache”

Then, following some forum advice, i typed

source ~/.bashrc

at the command line – this makes the bashrc file get read i think.

After that, i can install gems! Or at least, i could install hpricot, i didn’t try anything else.

However, the app still crashes when i require hpricot.

Looking at another forum post, it may be that the server doesn’t know where to look for them. They are in ~/.gems/gems (where ~ is the root folder)

James with some advice again, pointed me here.

Following this, i do the following. Go to my root and type ‘pwd’ – this gives me

/home/reeplies

- the location of my root folder. Next, i type

gem environment

and get the following

RubyGems Environment:
- VERSION: 0.9.2 (0.9.2)
- INSTALLATION DIRECTORY: /home/reeplies/.gems
- GEM PATH:
- /home/reeplies/.gems/gems
- /home/reeplies/.gems
- REMOTE SOURCES:
- http://gems.rubyforge.org

Then i make a new file called gemrc in the root directory, and put this into it:

gemhome: /home/reeplies/.gems/gems
gempath:
- /home/reeplies/.gems
- /home/reeplies/.gems/gems
Next, call

gem environment

again:

RubyGems Environment:
- VERSION: 0.9.2 (0.9.2)
- INSTALLATION DIRECTORY: /home/reeplies/.gems
- GEM PATH:
- /home/reeplies/.gems/gems
- /home/reeplies/.gems
- REMOTE SOURCES:
- http://gems.rubyforge.org

wait – i didn’t change anything! The environment’s the same! Never mind, carry on.

Next, i added the gem paths into environment.rb with this line:

ENV['GEM_PATH'] = ‘/home/reeplies/.gems:/home/reeplies/.gems/gems’

I’m guessing that the colon seperates items in a list of paths.

Next step: edit .bash_profile, which is again in the root directory. Added the following lines:

export GEM_PATH=/home/reeplies./gems/gems
export GEM_HOME=/home/reeplies/.gems

WAIT – i’ve been an idiot. I need to include the existing preinstalled gems as well – these are the paths for those:

gems folder is in /usr/lib/ruby/gems/1.8/
gem itself (the program) is in “/usr/sbin

and my local path is ‘/home/reeplies/.gems‘ (i think we miss off the last ‘gems’ as that’s the thing we’re locating).

Lets try again.

nope. OK, let’s try again with the extra /gems added to the paths – so they point to where the individual gems folders are rather than where the ‘gems’ folder is. So, this time

gems folder is in /usr/lib/ruby/gems/1.8/gems/
local path is ‘/home/reeplies/.gems/gems

OK, here we go again…

nope.

tried again with

gems folder is in /usr/lib/ruby/gems/1.8
local path is ‘/home/reeplies/.gems/gems

still no luck. arghhh.

james has fixed it, bless him. What a star. It was something to do with not using the nested gems folders after all i think.

made some more progress:

require ‘model_extensions’ ” wasn’t working because i had to copy over model_extensions.rb from my lib folder. Once done, this worked. Next problem was

“require ‘open-uri’ “. Open-uri is a standard component of ‘rubygems’, a list of standard gems usually installed along with rails/ruby, but it’s not in the installed version for some reason. Fortunately, i was able to get it by getting a list of all available gems with

gem list –remote >remote_gems_list.txt

and then doing

gem install ‘rubygems-update’

Sorted!

So, plugin/gem-wise, all i’ve got left is
#include Magick
#gem ‘actionpack-imagemagick’
#require ‘mini_magick’

Next step – did

]# script/plugin install http://opensvn.csie.org/rails_imagemagick_tag/imagemagick_tag/

Which installs imagemagick for rails. Testing – yes, my pictures work! Woohoo! (next stop movies, don’t want to think about that for now though). One problem with the pictures is that the thumbnail’s aren’t showing up. Let’s have a look at that…my local version’s showing them fine, maybe i didn’t set the thumbnail folder up? Nope, the folder is there, and there’s a correctly saved and named thumbnail in there. Let’s have a look at the page source (always a good start for debugging:

<img alt="Missing thumbnail" src="/data/pictures/thumbs/thumbpic1.jpeg?1190030080" />

Ah – see all those digits stuck on the end of the filename? I had that problem before! Argh, what was the solution…i remember getting help on a forum about it. Maybe i blogged it? Right – it’s something to do with the image_cache. It’s not the digits themselves, as my working local version has those as well, when i look in the source.

Found it – i’d commented out the following lines in the deployed version as they were making it crash -

imagemagick_for ‘/data/pictures’, :cache => ‘/data/pictures/cache’

On the web – sort of

September 14, 2007

My app’s up but not quite running. I’m getting this when i go to the beta url (which is http://beta.reeplies.com/public) :

Application error

Rails application failed to start properly”

Yesterday, Jay Gooby from the Brighton Ruby group kindly gave me several hours of his time to try and get Reeplies up and running. Here’s a breakdown of what i’ve done so far, before meeting Jay and with his help, as much for my own benefit as anyone elses.

Got my account with bluehost, which included free domain name registration with a years’ hosting (which cost about £45).

Got them to give me SSH access (i needed to provide some id, i emailed photos of the front and back of my driving license which was fine). They provided me with an ssh login and password. I learned that SSH is basically like telnet – a way of communicating with a remote host via the command line The difference is that the communication is encrypted, but that all happens under the hood – from a users perspective it’s like telnet.

Using the bluehost control panel, added an ftp account “max_williams@reeplies.com”. This created a subfolder called /public_html/max_williams.

Jay added another ftp account “beta@reeplies.com” which has the folder /rails/beta. This folder is to hold my working rails application folder.

Next step was to copy the application folder over! Bluehost provide their own ftp client for this but it’s a java applet and is a bit clunky. We used CoreFTP which i had already installed. We logged into beta@reeplies.com, and then just dragged the ‘newspipe’ (the working name of Reeplies) folder into the root directory (ie into rails/beta).

We were doing this using the wifi in the Windmill on montpelier terrace (nice pub btw – well kept ale and great chips) so the upload took a long time. Tip for anyone doing this – copy your app folder over to a temporary location and clear out anything you don’t need – saved files from the public folder and svn files for example. Then upload the cleaned up copy instead of your original folder. Obviously the PROPER way to do it is to get an online svn repository and install it from there. I’m working on it, for now the priority is to get SOMETHING up there.

Anyway, next step is to deal with Ruby gems and plugins: the host doesn’t have the ones i use, so i need to install them myself. According to Jay this is simple – we just go into the host unix environment (using ssh) and treat it like we would our own local command line. One difference is that the host is a unix environment whereas i’m used to windows: that means that some or all of the plugins/gems will use different versions to the ones i used.

To connect to the ssh command line i used PuTTY, with these connection settings:

Host name = reeplies.com
port = 22
connection type = SSH

(putty lets you save these details for future use)

So, now we’re on the remote server’s command line! Time for me to do a little bit of research into unix commands – i’ve never really ‘done’ unix. OK…

cd dirname – open directory – same as windows.
cd .. – go up – again same as windows
ls – list files and folders – like dir in windows

ok…

Next step was to get a mysql database up for my app to use. Created this using the bluehost control panel – a new mysql database called ‘reeplies_newspipedevelopment’ (it wouldn’t let us put underscores in for some weird reason, even though it adds the “reeplies_” prefix itself. Then, after the database.yml file had copied over, Jay changed it to point to the new database, and also set it so that it won’t be overwritten when i copy my files over.

I’m *not sure* whether we actually managed to set the database up, ie create all the tables and fields using my schema. There was an issue with rake – it didn’t seem to want to work. I think that this was maybe just because the files were still copying over the ftp. I just tried it now, but it’s having a problem because hpricot isn’t installed. hpricot is one of my gems (or is it a plugin?), so i guess all the gems and plugins need to be there before the migrate can happen.

Hmm. Think i’ll try commenting out those lines from environment.rb for now to see if i can get the migration to work…nope, now it has a permissions issue:

Access denied for user ‘max’@’localhost’ (using password: YES)
I’m a bit nervous about flailing around with this in case i break something. Think i’ll leave it till i get my next expert help session tomorrow from James McCarthy.

So, might as well get on with installing the gems and plugins! According to my environment.rb file, this is what i’m using (in future it would be a good idea to put in a comment next to them with the precise command i used to install them):

require ‘rubygems’
require ‘RMagick’
require ‘open-uri’
require ‘hpricot’ – used to get the title of a web page from a url
include Magick
gem ‘actionpack-imagemagick’
require “mini_magick”

Now, i remember reading about a ruby gem that basically takes all of your gems, and maybe plugins, that you’re using and does something with them that makes them easy to copy over. Looks like this is it – Rick Olsen’s Tzinfo: http://agilewebdevelopment.com/plugins/gems

Looks a bit complex – or rather, i’m nervous :) Going to try installing them one by one. Let’s do hpricot first as i think that was pretty simple (unlike rmagick/imagemagick).

hpricot: seems simple enough – just type

gem install hpricot

Gah, foiled again: i get a choice of versions (windows, jruby, ruby) and when i choose ruby i get:

ERROR: While executing gem … (Errno::EACCES)
Permission denied – /usr/lib/ruby/gems/1.8/cache/hpricot-0.6.gem

OK – time to mail the bluehost people i think…

OK – before i post my question, they suggest some previous replies that may be helpful. One of them is “How do I install my own Gems?”. Let’s have a look.

OK – according to this, i do the following: use their file manager to open .bashrc, which is in the root directory (back it up first). Then add the following lines to the end:

export PATH=”$PATH:$HOME/packages/bin:$HOME/.gems/bin”
export GEM_HOME=”$HOME/.gems”
export GEM_PATH=”$GEM_HOME:/usr/lib/ruby/gems/1.8″

export GEM_CACHE=”$GEM_HOME/cache”

Then connect to the site with ssh (i’m in there already), and enter the following in the root folder:

cp /usr/lib/ruby/gems/1.8/cache/sources-0.0.1.gem ./
gem install sources-0.0.1.gem
gem update -y

Did the first line, got a permission denied error again. OK, i’m mailing them now! Arggh, they’ve got no option to edit your ‘ticket’ ie your help request – it’s either send it or cancel it and start again! That’s really annoying. Going to have to rewrite it as i want to tell them that this other suggestion doesn’t work.

Follow

Get every new post delivered to your Inbox.