aboutsummaryrefslogtreecommitdiffstats
path: root/railties/doc
diff options
context:
space:
mode:
Diffstat (limited to 'railties/doc')
-rw-r--r--railties/doc/guides/getting_started_with_rails/getting_started_with_rails.txt41
1 files changed, 40 insertions, 1 deletions
diff --git a/railties/doc/guides/getting_started_with_rails/getting_started_with_rails.txt b/railties/doc/guides/getting_started_with_rails/getting_started_with_rails.txt
index a798bfa218..7a0d23777e 100644
--- a/railties/doc/guides/getting_started_with_rails/getting_started_with_rails.txt
+++ b/railties/doc/guides/getting_started_with_rails/getting_started_with_rails.txt
@@ -53,6 +53,7 @@ vendor/ Plugins folder
Rails comes with built-in support for SQLite, which is a lightweight flat-file based database application. While it is not designed for a production environment, it works well for development and testing. Rails defaults to SQLite as the database adapter when creating a new project, but you can always change it later.
Open up +config/database.yml+ and you'll see the following:
+
--------------------------------------------------------------------
# SQLite version 3.x
# gem install sqlite3-ruby (not necessary on OS X Leopard)
@@ -74,6 +75,7 @@ production:
database: db/production.sqlite3
timeout: 5000
--------------------------------------------------------------------
+
If you're not running OS X 10.5 or greater, you'll need to install the SQLite gem. Similar to installing Rails you just need to run:
`gem install sqlite3-ruby`
@@ -81,6 +83,7 @@ If you're not running OS X 10.5 or greater, you'll need to install the SQLite ge
Because we're using SQLite, there's really nothing else you need to do to setup your database!
=== Configure MySQL Database
+
.MySQL Tip
*******************************
If you want to skip directly to using MySQL on your development machine, type the following will get you setup with a MySQL configuration file that assumes MySQL is running locally and that the root password is blank:
@@ -89,7 +92,9 @@ If you want to skip directly to using MySQL on your development machine, type th
You'll need to make sure you have MySQL up and running on your system with the correct permissions. MySQL installation and configuration is outside the scope of this document.
*******************************
+
If you choose to use MySQL, your +config/database.yml+ will look a little different:
+
--------------------------------------------------------------------
# MySQL. Versions 4.1 and 5.0 are recommended.
#
@@ -146,6 +151,8 @@ Rails lets you run in development, test, and production environments (you can al
This will start a process that allows you to connect to your application via a web browser on port 3000. Open up a browser to +http://localhost:3000/+
+You can hit Ctrl+C anytime from the terminal to stop the web server.
+
You should see the "Welcome Aboard" default Rails screen, and can click on the "About your application's environment" link to see a brief summary of your current configuration. If you've gotten this far, you're riding rails! Let's dive into the code!
== Models, Views, and Controllers
@@ -159,10 +166,12 @@ Models in Rails use a singular name, and their corresponding database tables use
`./script/generate model Post`
You'll see that this generates several files, we're going to focus on two. First, let's take a look at +app/models/post.rb+
+
-------------------------------
class Post < ActiveRecord::Base
end
-------------------------------
+
This is what each model you create will look like by default. Here Rails is making the assumption that your Post model will be tied to a database, because it is telling the Post class to descend from the ActiveRecord::Base class, which is where all the database magic happens. Let's leave the model alone for now and move onto migrations.
==== Migrations
@@ -205,6 +214,7 @@ class CreatePosts < ActiveRecord::Migration
end
end
-------------------------------------------
+
Now that we have our migration just right, we can run the migration (the +self.up+ portion) by returning to the terminal and running:
`rake db:migrate`
@@ -224,9 +234,11 @@ The REST idea will likely take some time to wrap your brain around if you're new
* It is best to keep your controllers RESTful at all times if possible
* Resources must be defined in +config/routes.rb+ in order for the RESTful architecture to work properly, so let's add that now:
+
--------------------
map.resources :posts
--------------------
+
* The seven actions that are automatically part of the RESTful design in Rails are +index+, +show+, +new+, +create+, +edit+, +update+, and +destroy+.
Let's generate a controller:
@@ -234,10 +246,12 @@ Let's generate a controller:
`./script/generate controller Posts`
Open up the controller that it generates in +app/controllers/posts_controller.rb+. It should look like:
+
---------------------------------------------
class PostsController < ApplicationController
end
---------------------------------------------
+
Because of the +map.resources :posts+ line in your +config/routes.rb+ file, this controller is ready to take on all seven actions listed above. But we're going to need some logic in this controller in order to interact with the model, and we're going to need to generate our view files so the user can interact with your application from their browser.
We're going to use the scaffold generator to create all the files and basic logic to make this work, now that you know how to generate models and controllers manually.
@@ -251,11 +265,36 @@ Create the project again and enter the directory by running the commands:
=== Rails Scaffold
-Whenever you are dealing with a resource and you know you'll need a way to manage that resource in your application, you can start by generating a scaffold. The reason that this guide did not start with generating the scaffold is because it is not all that useful once you For our blog, we want our "Post" resource, so let's generate that now:
+Whenever you are dealing with a resource and you know you'll need a way to manage that resource in your application, you can start by generating a scaffold. The reason that this guide did not start with generating the scaffold is because it is not all that useful once you are using Rails on a regular basis. For our blog, we want a "Post" resource, so let's generate that now:
`./script/generate scaffold Post name:string title:string content:text`
+This generates the model, controller, migration, views, tests, and routes for this resource. It also populates these files with default data to get started.
+
+First, let's make sure our database is up to date by running `rake db:migrate`. That may generate an error if your database still has the tables from our earlier migration. In this case, let's completely reset the database and run all migrations by running `rake db:reset`.
+
+Start up the web server with `./script/server` and point your browser to `http://localhost:3000/posts`.
+
+Here you'll see an example of the instant gratification of Rails where you can completely manage the Post resource. You'll be able to create, edit, and delete blog posts with ease. Go ahead, try it out.
+
+Now let's see how all this works. Open up `app/controllers/posts_controller.rb`, and you'll see this time it is filled with code.
+
+Let's take a look at the `index` action:
+
+-----------------------------------------
+def index
+ @posts = Post.find(:all)
+
+ respond_to do |format|
+ format.html # index.html.erb
+ format.xml { render :xml => @posts }
+ end
+end
+-----------------------------------------
+
+In this action, we're setting the `@posts` instance variable to a hash of all posts in the database. `Post.find(:all)` or `Post.all` (in Rails 2.1) calls on our model to return all the Posts in the database with no additional conditions.
+The `respond_to` block handles both HTML and XML calls to this action. If we call http://localhost:3000/posts.xml, we'll see all our posts in XML format. The HTML format looks for our corresponding view in `app/views/posts/index.html.erb`.
=== The View
The view is where you put all the code that gets seen by the user: divs, tables, text, checkboxes, etc. Think of the view as the home of your HTML. If done correctly, there should be no business logic in the view.