June 15, 2013

Some time ago (November, 2012), I worked my way through the Ruby on Rails Tutorial by Michael Hartl. I liked it in many ways, but swore that I would like to do it again, leaving out all the test driven development and maybe even the git aspects of it so I could just learn rails.

• My notes on Hartl's tutorial

I am doing this on a Fedora 18 system, that shows (via rails -v) that I have rails 4.0.0.rc1. Forging boldly ahead (we could get sidetracked figuring out what rails 4.0 is all about and worrying about locking ourselves onto version 3.2.8 as per the tutorial, but we won't).

Initial setup

cd /u1/rails
rails new micromounts
cd micromounts
vi Gemfile

bundle update
bundle install
rails server

Random tips

Commenting out code in views can be a pain in the rear. You mix up ruby comments inside <% ... %> blocks with <!-- style html comments. And I found that I could disable a <%= block by jabbing a pound sign in the middle like so: <%#=.

There is a cool new ruby syntax that replaces :fish => 'trout' with fish: 'trout'. You can use this as you wish and feel cool and/or mix it with the old syntax (as I do by accident), which will confuse the poor innocents that follow.

Use git after all

git init
vi .gitignore
git add .
git commit -m "empty project"

And an amusing bit of trivia:

• DogBone - is called "camel case"
• dog_bone - is called "snake case"

A first cut at the database

rails generate model Mount myid:string species:string associations:string location:string
bundle exec rake db:migrate
rails generate controller Mounts new --no-test-framework

• notes:string
• source:string

• Rails Guides: migrations

I have some dates I want to load into the database, but these will go into the created_at and updated_at fields.

The database itself is in "db/development.sqlite3" Indeed I can run the sqlite3 command line utility on it and see the "mounts" table using ".table" and I can use ".schema mounts" to see the schema. But there is a better way (see my notes on sqlite manager below).

Later I decide to add some more fields. I could set up another migration to alter the database (and I would if I had data I wanted to preserve). However, I can just drop and regenerate the database without any trouble at this stage, so I edit my existing migration file to add the fields and then do:

bundle exec rake db:rollback
rm db/development.sqlite3
bundle exec rake db:migrate
minerals/minload

I actually do this several times over the course of a week during development. If I had data I needed to preserve, I would use layers of migrations, but this is clean and simple given that can reload the database at will, and am resisting the urge to add to and fiddle with the database.

Note that I am being manly and avoiding using rails scaffolds. Instead I am explicitly creating a model and a controller and making more work for myself, hoping that it will build character and add to my knowledge.

Loading the database -- and sqlite manager

I next find myself scrounging about for some kind of GUI database inspector in the flavor of "phpmyadmin" for the dreaded MySQL database. I come across a firefox plugin called sqlite manager. It is effortless to install. I restart firefox and ask "where the heck is it?" I might have used stronger words, I don't remember, but I looked in likely places, and fairly quickly found it under "Tools". I launch it, use database->connect to attach to /u1/rails/micromounts/db/development.sqlite3 and there I am looking at my data. Pretty doggone cool. It defaults to looking for extension ".sqlite", so to find my database (with extension .sqlite3), I had to select "browse for all files".

Getting ready for actual rails hacking

You can't climb a dozen learning curves all at once (unless maybe you are young and smart like Dallan), so I make do with the current state of my vim knowledge and swear that when this is done, I will learn to do better.

For now, I use my "trails" shell script to give me a cluster of terminal windows, each in a sensible place in the rails directory tree for this project.

• Notes on my rails terminal scheme

Eruby

• <% ruby %>
• <%= ruby %>
• <%= ruby -%>

Routes

I note that in the new rails 4.0.0 I am using, the file public/index.html that it used to be a tradition to delete has vanished, which is OK. As soon as I add a route for root this no longer appears at the root of my site (which instead now goes to the index action).

I glance at this:

• Rails Guides: Rails Routing from the outside in

Actually I should probably read this several times, along with other things among the rails guides. The game though for now, me being impatient and lazy, is to hack around in config/routes.rb. I first add a bunch of Get entries, then decide that just having a root entry and declaring a resource for "mounts" gives me what I want for now. Then I edit the controller to add corresponding actions and I add files to the view directory to provide views for the various actions. Pretty soon I have:

• localhost:3000 goes to the index action of the Mounts controller
• localhost:3000/mounts/13 goes to the show action of the Mounts controller
• localhost:3000/mounts/13/edit goes to the edit action of the Mounts controller

Redirect, Render, or ...

• The method just "falls off the end" - in this case the view with the same name as the method (action) in the controller gets handed to the browser. So, let's say routing selects the dog_controller and action "fido", then the view fido.html.erb will get rendered. Note that there need not even be such an action in the controller, if not then there is nothing to do but render the view with the same name as the action that would have been run.
• A call to "render" is given which specifies a view to be rendered. Note that the controller should then (in general) immediately return.
• A call to "redirect_to" is given (after which the controller should immediately return). What happens here is that a redirect is sent to the browser instead of rendering a view. The browser then throws that right back at the rails routing system and away we go again.

link_to

link_to "Edit", edit_mount_path

link_to "Show", @mount

Good practices encourage me to persist in using this (rather than wiring in explicit URL's) because it will make the code easier to maintain and robust in cases where I rearrange the site or its location.

Pagination

vi Gemfile
  gem 'will_paginate', '3.0.3'
bundle install

• The form will do a POST, and subsequent pagination does a GET. This means you have to set up routes for each that lead to the same controller action.
• I have to use the session to carry the search paramters for subsequent paginations.

Layouts

Stylesheets

#dingus {
    color: red;
    font-size: large:
    font-weight: bold;
}

To specify style for an "class" use .dingus instead of "#dingus"

Using this and "div" give you lots of control.

Remember use "id" for some one of a kind thing in your layout and use "class" for things that there are many of.

Partials

<%= render :partial => 'mount' %>

<%= render :partial => 'mount' :object => @this_mount %>

<%= render :partial => 'mount' :object => @this_mount, :locals => { :var => true } %>

Helpers

Forms

<%= form_for @mount, :url => { :action => 'update' } do |form| %>
<% form_for @mount, :url => { :action => 'update' } do |form| %>

You can choose between "FormHelper" and "FormTagHelper". FormHelper is meant to work with ActiveRecord objects, while the methods provided by FormTagHelper are not (so can be used to generate arbitrary forms I guess).

• Ruby Guides - form helpers

Rails 4.0 Strong Parameters

It raised its head for me when I did this:

@mount.update_attributes(params[:mount])

This site gave a cogent and understandable explanation of what this is all about. To get things going, I change the line above to:

@mount.update_attributes(mount_params)

AJAX and Javascript in Rails

This is a significant topic of its own, which I a going to discuss in detail in a separate document:

• My notes on rails and ajax

It turned out that I didn't need to write any Javascript for what I was doing (although it might serve me well in the long run). What I wanted to do was to have a column of checkboxes along a big paginated index that let me select this and that. When I click the checkbox (or unclick it), I want to see an Ajax event call some action in my controller. I stumbled around with lots of examples that use non-coffeescript javascript and wrapped the checkbox in a form (which I wanted to avoid, though it could have advantages for bundling a hidden field that would set a parameter for when the box gets unchecked, but we made do without all of that.

The line in the view that produced my checkbox looked like this:

<%= check_box_tag( 'label', 1, mount.label != 0,
            data: { remote: true, url: url_for( action: :label_create, id: mount.id ) } ) %>

def label_create
        # When the box gets checked, we get the label param set,
        # When it gets unchecked, it is not set at all.
        # also ... mighty fast and loose with error checking.
        if params[:label]
            add_label params[:id]
        else
            label = Label.delete_all mount_id: params[:id]
        end
        # This is Ajax, so we don't render anything.
        render :nothing => true
    end