Fuel Your Coding » Ruby on Rails

Getting Started with jQuery Mobile & Rails 3

Jerod Santo — Tue, 26 Oct 2010 13:06:15 +0000

The very promising jQuery Mobile project is now in its first Alpha release! What better time to give it a spin with our (err… my) favorite web framework?!

You should read jQuery Mobile’s official introduction section to familiarize yourself with its principles, but in a few words: you include it on the page, format your markup to conform to its requirements and reap the benefits. Yay, let’s write a (very contrived) CRUD application with Rails 3 and jQuery Mobile!

Setup

Our application will allow us to create, read, update and delete blog posts (remember when I said it was contrived? Uhm..yah) from mobile devices. If you don’t have Rails 3 installed yet, you can get it via RubyGems:

gem install rails

Use the rails command line tool to generate a new application. We’ll call it jqmoblog.

rails new jqmoblog
# ... a bunch of files are created
cd jqmoblog

As of Rails 3.0.1 you cannot specify jQuery as the JavaScript tool of choice when you generate a Rails application, but we can easily swap it in by using the handy, dandy jquery-rails gem. Edit the Gemfile in the project’s root directory and add a dependency on the gem. Once finished your Gemfile will look something like this:

source 'http://rubygems.org'

gem 'rails', '3.0.1'
gem 'sqlite3-ruby', :require => 'sqlite3'
gem 'jquery-rails'

Install the required gems using the bundle command line tool:

bundle install

Now we’ll use the Rails generator added by the jquery-rails gem to get all the jQuery files we need:

rails generate jquery:install

When prompted, allow it to overwrite rails.js.

We’re almost ready. The application skeleton is in place and jQuery has replaced the Rails default JavaScript libraries, but we’re missing the basic model, controller, and views for our application.

Thankfully, Rails has a generator which will create these files for us and its called the scaffold generator. We’ll keep the blog posts in our app super-simple since we’re really just using them to learn about jQuery Mobile. Each post will have a title and a body. Generate the scaffold for a Post resource like this:

rails generate scaffold Post title:string body:text

This command will provide a list of files and directories it created. There should be a model (app/models/post.rb), a controller (app/controller/posts_controller.rb), and a directory of views (app/views/posts) for our Post resource.

Run the database migration that was created from the scaffold command so our database has a posts table with the required columns for storing our posts:

rake db:migrate

At this point you can fire up a Rails server and the app will load up in your browser:

rails server

Point your browser to http://localhost:3000 and you should see this:

Hmm, before we get to mobilizing this application, let’s make the root url load the list of our posts instead of the default Rails index file:

rm public/index.html

Edit the config/routes.rb and set the root route like so:

Jqmoblog::Application.routes.draw do
  resources :posts
  root :to => "posts#index"
end

Now load up http://localhost:3000 again and you should see the empty list of posts.

We still need to get the jQuery Mobile files on the page. Lets use the ones hosted on jquery.com. Add them to the application’s layout file so they’ll be on every page that gets served. In app/views/layouts/application.html.erb, edit the head section to look like this:


  Jqmoblog
  
  <%= javascript_include_tag :defaults %>
  
  <%= csrf_meta_tag %>

Okay, everything is in place. Now we’re ready to turn this into a mobile app!

Getting Started

Before we flesh out our mobile CRUD actions, let’s get the posts index looking decent in mobile browsers. jQuery Mobile relies directly on the page’s markup to work its magic, so to invoke it we just need to change our views to conform to its conventions.

Each “page” in a jQuery Mobile application needs to be wrapped in a div with a data-role attribute of page. I put “page” in quotes because there can actually be many of them on a single webpage loaded from the server. In our app we’ll be loading each “page” from Rails, so we should just add this to our layout file which will wrap each of our individual views:

Before


  <%= yield %>

After


  
    <%= yield %>

Next edit the post’s index (index.html.erb) and change the markup to create a header and a content section which lists all the posts in the database.

Before

Listing posts



<% @posts.each do |post| %>
  
<% end %>

  
    Title
    Body
    
    
    
  

    <%= post.title %>
    <%= post.body %>
    <%= link_to 'Show', post %>
    <%= link_to 'Edit', edit_post_path(post) %>
    <%= link_to 'Destroy', post, :confirm => 'Are you sure?', :method => :delete %>
  




<%= link_to 'New Post', new_post_path %>

Title	Body
<%= post.title %>	<%= post.body %>	<%= link_to 'Show', post %>	<%= link_to 'Edit', edit_post_path(post) %>	<%= link_to 'Destroy', post, :confirm => 'Are you sure?', :method => :delete %>

After


  Listing posts



  
    <% @posts.each do |post| %>
    
      <%= link_to post.title, post %>
      <%= link_to 'edit post', edit_post_path(post), "data-icon" => "gear" %>
    
    <% end %>

Load up the page and it should look like this:

Two things to note here. First, we are once again using the data-role attribute to create the header and the styled list. This is a major theme of jQuery Mobile (as of the Alpha, I’m told they *might* be switching to class names instead of data- attributes). Second, each list item has two links, and jQuery Mobile automatically knows that this means we want to use a split button list. Pretty cool, huh?

Let’s add a button which will take us to a page where we can create new posts. Add this line to the end of the header div:

<%= link_to 'Add', new_post_path, "data-icon" => "plus", "class" => "ui-btn-right" %>

Again, jQuery Mobile “just knows” that this should be a button in our header and we pass it a class and a data-icon attribute to tell it where to place it and which icon to use. We now have a button in the header which links to the new post path!

Create

We’re gonna need to create posts so we can read, update and delete them, so lets handle creation first. The “Add” button on the posts index links to the new.html.erb view. It works as is and looks okay too. We’ll just tweak the markup to make it fit into the jQuery Mobile styles:


  New Post



  <%= render 'form' %>

We can now add new posts using the mobile interface! Go ahead and create a few so the posts index shows a list with links to edit each post:

Read

People will read posts from their show.html.erb view. Again, no change to the underlying controller or model code needs to happen. Just update the view file to look like this:


  <%= @post.title %>
  <%= link_to 'Home', posts_url, "class" => "ui-btn-right" %>



  <%= @post.body %>

Update

When we set up the posts index we added links to the edit.html.erb view using the gear icon on the right side of the split list. Now we just need to change the markup on that view to conform to jQuery Mobile’s requirements. Have you sniffed out a pattern to this development process yet?


  Editing Post



  <%= render 'form' %>

Again, it just works as expected and it will look great on many mobile devices. On to the final action, delete!

Delete

To facilitate deleting a post we just have to modify the delete links created by Rails’ scaffold generator to fit the rest of the mobile site. I think the edit page is a good place to add a delete link, so lets add a button to the header of edit.html.erb:

<%= link_to 'Delete', @post, :method => :delete, "data-icon" => "delete", "class" => "ui-btn-right" %>

The edit view is now complete, and it lets us update and delete our post.

Closing Up

If you’ve made it this far, you’ve probably realized that working with jQuery Mobile is pretty painless and it fits in with Rails quite well. There are a bunch of other things that jQuery Mobile can do, but this should hopefully whet your appetite. Remember, the framework is still in the Alpha stage so things can and probably will change.

I encourage you to read more about the project and get involved at an early stage so we can all benefit from a strong community!

***Download the source code for the application built in this post***

Set Rails Logging on Fire

Jerod Santo — Fri, 19 Mar 2010 17:10:14 +0000

&c=" border="0" alt="" />

Advertise here via BSA

Rails 2.3+ and Rails 3 rely on Rack, a minimal (and awesome) interface between Ruby and webservers. This has many advantages, one of which is the ability to easily swap Rack applications (middlewares) in & out of your Rails app. Modularity FTW!

One fun (and useful) example of a Rack middleware is a Firebug logger written by Simon Jefford for the CodeRack competition. This middleware allows you to send arbitrary messages directly to Firebug. Why? Since you’re already debugging much of your Rails app in a browser anyway, sending debug output to your browser’s console (instead of tailing a log file) makes a lot of sense.

NOTE: FirebugLogger plays nice with WebKit’s Web Inspector as well.

Simon also released a Rails plugin that you can install to set up the middleware for you, but it’s more fun (and informative) to set it up yourself. Here’s how:

Setup

The goal is to be able to send arbitrary messages to Firebug from any controller or view.

Rails autoloads (and namespaces) any code placed in the lib directory, so that is where we’ll place our FirebugLogger code. Grab the code from my gist, which is a fork of Simon’s original with minor improvements, and place it inside your Rails app in:

lib/rack/firebug_logger.rb

Rails will load the code for us, but we need to manually activate the middleware. Since this bit of code is only useful during development, we’ll load it up in that environment only.

# config/environments/development.rb
# ... other stuff ...
config.middleware.use ::Rack::FirebugLogger

Using FirebugLogger

Using the middleware is pretty straight forward. It will process an array of arrays, each of which has a log level and a message. Add a single line like the one below to an existing controller action and load up the page:

# app/controllers/posts_controller.rb
class PostsController < ApplicationController
  def index
    @posts = Post.all
    request.env['firebug.logs'] = [[:info, "hello from rack!"]]
  end
  # ... other actions ...
end

Open Firebug and you should see “hello from rack!” glaring back at you. You can do the same thing in views:

# app/views/posts/index.html.erb
<% request.env['firebug.logs'] = [[:warn, "inside a view!"]] %>

Adding a Helper

Using the logger like this is a bit tedious, and it’s not easy to create multiple messages for a single request. Let’s wrap the functionality up into a method that we can call. This method should be placed in the application controller so that all other controllers inherit it.

# app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
# ... other stuff ...
helper_method :firebug

  private

  def firebug(message,type = :debug)
    request.env['firebug.logs'] ||= []
    request.env['firebug.logs'] << [type.to_sym, message.to_s]
  end
end

This method will initialize an empty array the first time it is called and then push new messages on to the array on subsequent calls. Notice that it calls to_s on the message variable before passing it on. This means you can send the method a string or any object that responds to to_s and it will just work. Specifying a log type is optional, the method is private and it is explicitly added as a helper_method so that you can access it from views as well.

Now writing logs to Firebug is as easy as:

firebug "woop woop!"
# optionally specify a log level
firebug "it's a trap!", :warning

Here are a few ideas of helpful messages to send to Firebug:

# inspect the attributes of an object
firebug @posts.first.inspect
# dump the session
firebug session
# check a user's roles
firebug current_user.roles.inspect

I highly encourage you to try this in one of your Rails apps. It has proven a useful addition to my toolkit. Let me know how it works for you by leaving a comment!

Creating Your First Ruby on Rails Application From Scratch

Mageshcse — Tue, 18 Aug 2009 16:14:31 +0000

&c=" border="0" alt="" />

Advertise here via BSA

This tutorial which will help you create a basic Ruby on Rails application, without worrying too much about Ruby basics for now. Well, if you want to learn more about Ruby or Rails basic concepts, please refer the following links:

And if you need more help, you can hit the #railsbridge channel of freenode IRC.

So what are you waiting for? Lets get started with creating our basic rails application!

Getting Started

What is Ruby

Ruby is one of the easiest scripting languages I have ever seen; simple enough for non-tech people, powerful enough for advanced programmers and best of all, it doesn’t have a complex syntax or keywords to be memorized. Instead it is written in a simple English syntax.

What is Rails

Rails is a web development framework written in the Ruby language, which has a general MVC (Models, Views, Controllers) type of structure to make everything simple for the developers. It allows you to write less code but accomplish more than most other languages/frameworks.

Rails MVC Architecture

Rails has a MVC (Models, Views, Controllers) architecture and its benefits include:

Isolation of business logic from the user interface

Ease of keeping code DRY

Making it clear where different types of code belong for easier maintenance

From Getting Started With Rails

Models

A model represents the information (data) of the application and the rules to manipulate that data. In the case of Rails, models are primarily used for managing the rules of interaction with a corresponding database table. Most often, a single table in your database will correspond to a single model in your application. The bulk of your application’s business logic will be concentrated in the models.

Views

Views represent the user interface of your application. In Rails, views are often HTML files with embedded Ruby code that performs tasks related solely to the presentation of the data. Views handle the job of providing data to the web browser or other tool that is used to make requests from your application.

Controllers

Controllers provide the “glue” between models and views. In Rails, controllers are responsible for processing the incoming requests from the web browser, interrogating the models for data, and passing that data on to the views for presentation.

Welcome to Rails!

Now lets create the sample ‘Slambook’ Application.

Requirements:

Install Ruby and RubyGems

Install Rails

Install SQLite, Postgres or MySQL

(Note: I will be using ubuntu (linux) and Postgres for building my rails application, but you can also install rails on your Windows or Mac machine as well.]

Once you have everything installed, we can start creating our rails application. To begin, open a terminal (Console, Command Prompt, etc) and type the command:

 rails slambook

For this example we will use ’slambook’ as the name of the application which we will build. As soon as you hit enter, you will see the scripts flow in your terminal creating a bunch of files (as seen in the picture below):

These are the files which rails automatically generates to create the framework for our application.

Now just change the directory to our application using:

 cd guestbook

and feel free to explore all the sub-directories and the files inside it to get an idea where the code lives.

Now, lets test if your rails application is working by using the command:

script/server

Open your favourite browser and type http://localhost:3000/ in the address bar and press Enter.

If you see a page similar to the above image, then your first rails application works fine (pat yourself on the back, you got it right)!

To start off, we are going to create the needed controller, model and views for our guestbooks post functionality which allows your friends to sign your ’slambook’.

Using the command:

 $script/generate scaffold post name:string address:text dob:date desire:text interests:text hobby:text signature:text

Scaffold command creates a CRUD (Create, Read, Update, Delete) interface for your app ( a quick way of creating the MVC automatically). Alternatively, you can also create your controller, model and view manually using the command

 $script/generate controller  // for creating controller and views

 $script/generate model  // for creating model

Here we are telling rails that we want code generated to handle a “Post” model, which has a string type for name and text for address, date for dob and so on. Notice this will generate some more files, one of which is the database migration file found inside the db/ directory

This is how our first migration file looks (slambook application):

The migration files are used for managing the CRUD (create, read, update and delete) activities of the database. If you haven’t created your database yet we can do it by a command:

 $rake db:create

Now you might wonder how rails connects our database, and for this purpose we provide our database information in the database.yml file which is found inside the config/ directory:

This is how the database.yml file looks. We mention our database name and user details for rails to make the connection.

Since now we have recently created a new model for Post, a table must be created in our database and requires that we upgrade the database using this command:

 $rake db:migrate // (instead of creating/updating the database table manually)

This updates the database with the information from the migration file.

(Note: when this command is executed, the migration file inside the db/migrate/ directory say 20090718013114_create_posts.rb is used as an reference for updating the database)

Now lets checkout what we have done so far:

 $script/server

As before, open your browser and type http://localhost:3000/posts in the address bar and press Enter to see your application:

If your page looks like that, then shout “Wow! I have created my first rails application!”

The page at http://localhost:3000/posts shows the list of post made in your guestbook. Note there you have a link “New Post” which links to the the page at http://localhost/posts/new where your friends can sign your guestbook. You must wonder how these pages were created, so take a look at the app/views/posts directory which contains the html pages that were created by the scaffold command. These html pages have .html.erb extension which means ruby code can be embedded in your html files.

Now lets create a home page for our ’slambook’ application:

 $script/generate controller home index

This creates a controller “home” along with views in the app/view/home directory. Rails will create several files for you, including app/views/home/index.html.erb file. This is the template that we will use to display the results of the index action (method) in the home controller. Open this file in your text editor and edit it to contain the code that you want to display in your index page:

 Magesh's Slam-book or Guestbook
 <%= link_to "View my book", posts_path %> <%= link_to "Sign my book", new_post_path %>

The last two lines have added two links in my home page, one for people to view all the posts in my slambook and the other for new friends to use to sign my slambook.

tag is used to display the link. posts_path links to the posts/index page and new_post_path links to the posts/new page.

I suggest you also open the other .html.erb files in app/views/posts directory like index.html.erb, show.html.erb, edit.html.erb and new.html.erb to have a look around. Their functions are described in the file posts_controller.rb (controller) inside the app/controller directory.

Dont get confused with the above image, I will tell you how it works:

Lets take the index method first:

def index @posts = Post.all respond_to do |format|
format.html # index.html.erb
format.xml { render :xml => @posts }
end

@posts variable stores all the posts and format.html is used to render the index.html.erb file in the app/views/posts directory.

Similarly the other methods such as new, edit and show are created. Notice that the methods inside the posts_controller.rb file are related to the files inside app/views/posts directory.

The show method renders the app/views/posts/show.html.erb file and in the same way the edit method renders the app/views/post/edit.html.erb file.

When you hit http://localhost:3000/ in your browser you should get the rails default page instead of our home page. That is because rails has created a default index.html page in the public directory. Since we want to use the home controller to show the index page instead of the rails default page ( public/index.html ), we must delete that public/index.html file first:

 $rm public/index.html

and then tell rails to point to home controller as the default index page. That is done by editing the config/routes.rb file (rails routing)

Rails routing?

You can learn more about routing by reading Rails Routing from the Outside In.

Edit config/routes.rb in your favorite editor (I prefer emacs)

 ActionController::Routing::Routes.draw do |map|
map.resources :posts
map.resources :home
map.root :controller => "home";
map.connect ':controller/:action/:id'
map.connect ':controller/:action/:id.:format'

Note: Whenever a controller is created we need to inform rails about it using the map.resources : which creates the url say http://localhost/ in our application.

Also check out the 4th line: map.root :controller => “home” tells rails to load the home controller for the default home page.

Now visit http://localhost:3000/ and you should see our new home page:

Conclusion

So this is just the skeleton of our application. We obviously should add CSS to design our rails application to make everything look better!

I hope this helps you start Ruby on Rails with ease! If you have any queries or are facing any problem while trying out this on your machine please feel free to shout your comments below. ;)