Register

If this is your first visit, please click the Sign Up now button to begin the process of creating your account so you can begin posting on our forums! The Sign Up process will only take up about a minute of two of your time.

Results 1 to 8 of 8
  1. #1
    Senior Member
    Join Date
    Jun 2005
    Location
    Atlanta, GA
    Posts
    4,146
    Member #
    10263
    Liked
    1 times
    A Ruby on Rails Tutorial: Blogification, Part 1
    This is a Ruby on Rails tutorial! If you're not sure what in the world Ruby on Rails is, it's a web application framework built using the Ruby language. For more information on these, see the Ruby website and the Ruby on Rails website.

    The key point of Ruby on Rails is convention over configuration. What does this mean? Rails uses sensible defaults, and, if you follow those defaults, the amount of configuration you have to do is almost nonexistent. This is in part to attempt to escape the XML forest that springs up for any given J2EE project, for example. And it is also an attempt to reduce the amount of work the programmer has to do -- something Ruby itself tries to do as a language, as well.

    The second key point of Rails is Don't Repeat Yourself. What does that mean? That means you don't have to include files that fit together naturally. It means you don't have to redeclare the columns that are in your database when they're already defined in the database.

    For purely informational reading, the Wikipedia pages for Ruby on Rails and Ruby are inteteresting.

    What Are We Doing?
    So what am I going to show you how to do? The idea came up to make the world a better place by doing yet another blog tutorial. The idea here is, however, to go quite a ways with this blog. This tutorial will walk you through the basics of RoR while designing a database structure capable of dealing with the blog. Subsequent tutorials will explore other features like tagging, logins, and even CAPTCHA. At least, that's the plan. Let's not get ahead of ourselves, now; we'll focus, for the moment, on the basics.

    Do note that the tutorial isn't exactly *short*, but it covers the basics of coding in Rails. The idea is that you can refer back to parts of this tutorial when you forget how to do simple little things. In fact, I'll probably be referring back to it for a while, too :-)

    On Audience
    So who should read this? Well, I'm assuming, if you're reading this, that you at least have some idea of Ruby. Much of how Ruby itself works can probably be inferred from the examples of code you'll see here; still, it's always a good idea to have a decent grasp of a language before you start using frameworks built on top of that language. Then again, I'm the kind of guy who learns by example, which means I actually learned Rails as I was learning Ruby.

    Anyway, if you've never heard of Ruby, but already know how to program in an OO language like Java or C++, I've written `A Superfast Guide to Ruby', which should get you started more or less quickly with the language.

    That said, on to installation!

    Installing Rails
    Rails is a fairly painless install, thanks in large part to RubyGems, the Ruby package manager.

    If you're running Windows, see my Ruby tutorial for instructions on how to install Ruby and RubyGems. Linux users, you can use your package manager to install these two. Mac users, see the tutorial above for a link to a tutorial to install a fixed Ruby.

    Once you've got RubyGems, all you have to do is run [minicode]gem install rails[/minicode] and everything will automagically get installed for you. Cool, huh?

    Finally, you'll need a database. I'd recommend MySQL, just because it's widely used, though other options such as PostgreSQL are also quite good (which is better tends to be a matter of perennial flamewars, so we'll dodge the issue entirely and say `use whichever suits you best'). You'll also probably need some sort of frontend for whichever one you use; I'll leave it up to you to find one that suits you (I tend to run an Apache+PHP server and MySQL, so I use phpMyAdmin.

    Example Server

    I've actually set up an example server for this Rails application that you can play around with at http://blogification.savedfastcool.com/ . The index page is currently the default Rails index, just like it will be at the end of this tutorial; to do something useful, go to either [minicode]/post/list[/minicode] or to [minicode]/user/[/minicode]. The server version will follow along as I make the improvements in future parts of this tutorial.

    Getting Started
    Getting started in RoR is frighteningly quick. First of all, create a directory that you want to use for your project. We'll call ours `blogification', because... Well... Just because :-P You'll want to do some of this, at least, on the command line, and it's always a good idea to have a command prompt open while doing things in Rails, since some of the utilities run on the command line and can make your life a lot easier. So, let's make the directory:
    Code:
    > mkdir blogification
    > cd blogification
    Now, we want to initialize the RoR system for our application. You might think
    `oh no, what do I have to do?' It turns out, it's a pretty easy one:
    Code:
    > rails ./
    That's it! Rails will create a full directory structure and copy a bunch of helper scripts into the directory, including a light, all-Ruby web server you can use for testing called WEBrick.

  2.  

  3. #2
    Senior Member
    Join Date
    Jun 2005
    Location
    Atlanta, GA
    Posts
    4,146
    Member #
    10263
    Liked
    1 times
    On Model/View/Controller
    A particularly well-known design pattern in the software world is the Model-View-Controller pattern. The idea behind this design is that there is a model that takes care of data and how data is manipulated, fetched, and handled, and then there's a view, which does nothing but display the data. The controller bridges the gap between the two by, for exmaple, formatting the data from the model for the view, or giving the view whatever part of the model it's going to show. This separation of logic and presentation proves so useful that almost every technology tries to achieve it. Even when we program XHTML+CSS+JS, it is best to separate the structure (XHTML) from the presentation (CSS) from the extra logic (JS).

    Ruby on Rails codifies this MVC pattern by creating everything around the paradigm. You create views -- rhtml files -- that display information; you have models -- ActiveRecord objects that contain the database information -- for handling all database objects; finally, you have controllers, which take data from the models and pass it on to the view, or take the input from the view and save it to the model.

    First Steps in the Database
    Now comes the first step: let's create a table in the database. I'll assume you've created a `blogification_development' database that we'll be doing all our work in, by the way. We'll call our table `posts' and give it the following columns:
    Code:
    id       Integer, auto incrementing, primary key.
    title    String.
    content  Long string.
    user_id  Integer, used for associations with a users table.
    Now, we'll also create a `users' table with the following fields:
    Code:
    id       Integer, auto incrementing, primary key.
    username String.
    name     String.
    Great, now we're ready to configure Rails to understand our database. We need to open the file [minicode]blogification/config/database.yml[/minicode]. You'll notice in this file there are three sections: `development', `test', and `production'. We're interested in the first one, `development', for now, but it's worth noting the other two. The `test' database is used when running unit tests (which are integrated with Rails quite well), while the `production' database is used when deploying in production mode (where changes to the running application are not permitted without special voodoo).

    Anyway, fill in your adapter, your database name, your username, your password, and your host (usually localhost in our case).

    Running WEBrick
    WEBRick is the all-Ruby, lightweight web server you can use to test your RoR application. You run it from the command line. Go to your `blogification' directory and run:
    Code:
    > ruby script/server
    This will start WEBrick, usually listening on port 3000. If you point your browser to [minicode]http://localhost:3000[/minicode], you should find the RoR welcome page.

    WEBrick, much like PHP, and much unlike Java, will automatically run any changes you make to your application while it's running in development mode. Thus, if you want to check if an item is nil, you can simply add a print statement and reload the page without having to wait for a redeploy or restarting the server.

    Now, let's use Rails, shall we?

    Washing Windows With Some Scaffolding
    The first thing we need to do in order to use the database entries we made is to create models for the posts and users tables. A model in RoR represents a single row of a single table. We mentioned earlier that Ruby on Rails follows the idea of convention over configuration. This is where we'll talk about the convention.

    Rails expects you to use a convention when naming your database tables and fields:
    * Tables are plural names (posts) of singulars (post).
    * [minicode]id[/minicode] is the primary key.
    * Linking with other tables is done via singularname_id (i.e., user_id).

    These are fairly straightforward rules to follow. A few more will come up as we go along, but these are more than enough for now. The question is, why does Ruby expect plural names for tables? Easy -- because your model is named the singular. So, if you have a `posts' table, you will get a `Post' model. Similarly, the `users' table will give us a `User' model. It bears mentioning that the folks who made RoR made it handle English plurals correctly. Those of you who are aware of just how incredibly nutsy English pluralization rules are will understand just how large a feat this is. `people', for example, will map to a `Person' model.

    Anyway, enough about that, let's create our models! Rails, it turns out, provides us with a script to do that, too:
    Code:
    > ruby script/generate model Post
    > ruby script/generate model User
    This will create a bunch of files, including testing files, for your models, as well as the classes themselves.

    Here, we'll take another second to observe a naming convention for Ruby in general. Class names are done in CamelCaps (while this isn't mandated, it's standard, and the first letter MUST be an uppercase letter); their files, however, are done all-lowercase with underscores (_) between words. For example, if we has a class SuperMan, the file it would be in would be called [minicode]super_man.rb[/minicode]. Rails follows this convention.

    Now, before we create our controllers, we'll let the models know about their relationship. Open [minicode]app/models/post.rb[/minicode] and make it look like this:
    Code:
    class Post < ActiveRecord::Base
        belongs_to :user
    end
    You just told the post it belongs to a user. Now, let's let the user know it can have many posts ([minicode]app/models/user.rb[/minicode]):
    Code:
    class User < ActiveRecord::Base
        has_many :posts
    end
    Notice, again, how this reads like English -- we pluralize `posts' because it makes sense when we're writing it. Rails will take care of figuring out that we're referring to the Post model.

    Now, we can create our controllers:
    Code:
    > ruby script/generate controller Post
    > ruby script/generate controller User
    Again, several files will be created. When we generate our controllers, a view folder is also generated, though nothing goes into it. We'll get into that in a little bit. First, though, let's make our application do something. Don't worry, this isn't another four pages worth of text. We'll bring our application to life with one line added to each of our controllers. First, our post_controller.rb file (in [minicode]app/controllers/post_controller.rb[/minicode]):
    Code:
    class PostController < ApplicationController
        scaffold :post
    end
    And then, in our user_controller.rb file:
    Code:
    class UserController < ApplicationController
        scaffold :user
    end
    Now, run WEBrick if you haven't yet and go to [minicode]http://localhost:3000/posts/[/minicode]...

    Nothing too much, right? Now click on `New post'. Fill out the form and click `Create'. You can do the same with users at [minicode]http://localhost:3000/users/[/minicode]. This is what we call `scaffolding'. RoR has given you, for free, basic views and actions such as new, list, edit, show, and delete. Pretty neat, huh? Hell, you could almost say we're done, yeah? Okay, maybe we need to add a little something more, even for this basic a tutorial :-)

  4. #3
    Senior Member
    Join Date
    Jun 2005
    Location
    Atlanta, GA
    Posts
    4,146
    Member #
    10263
    Liked
    1 times
    Replacing the Scaffolding
    Though Rails provides us with an excellent platform to start from in the form of the scaffolding we've just seen in action, there are some things this scaffolding doesn't provide; for example, in our case, we want to associate a blog post with a user. So, we're going to replace RoR's default new and edit functionality to allow us to select what user made the post; in addition, we're going to replace the list functionality to display the associated user, as well. Finally, we're going to spice things up just a little with some styling.

    Let's start at the beginning, though. In order to override an action that is provided by the scaffolding, we need to first override the associated method in the controller. In this case, we're playing with the Post controller. Once again, we run into the convention over configuration concept of Ruby -- the /post/new action calls the PostController class's `new' method.

    This is the point at which we should mention that views run as `part' of a controller. That is to say, instance variables that belong to the controller are also available to the view. So, if we want to access anything in the view, we need to set an instance variable in the controller. Can you think of anything we might want to access in the view? How about a list of users?

    So now we know that our `new' method needs to fetch a list of users and make it accessible. Will we need to tell the view to render itself somehow? Actually, no. Again, convention over configuration. When the new method returns, Rails automatically renders the template in [minicode]/app/views/post/new.rhtml[/minicode]. All that said, it looks like our `new' method is going to be pretty short; and indeed, it is:
    Code:
        def new
            @users = User::find_all
        end
    Aaand that's it. We've just asked the User object to get us all of its instances in the database. It will return an array which we can then use in the view. It bears mentioning here that we could also have written this [minicode]User.find_all[/minicode]; however, I prefer to use the C++ :: syntax to clearly differentiate calls to static methods.

    Now that we've got this, we need to create the view. As mentioned above, we can create a [minicode]new.rhtml[/minicode] file in [minicode]/app/views/post[/minicode]. Here's what it'll look like:
    Code:
    <select>
    <% for user in @users %>
        <option><%= user.name %></option>
    <% end %>
    </select>
    Before we test it, make sure you create a user in the users table by going to [minicode]/user/new[/minicode]. Then, point your browser to [minicode]/post/new[/minicode] and see the user show up in the select box. Now, while we love referring to users by name in Real Life (tm), in the database, we said we were referring to them by id (the argument of making the username the primary key is a good one, but let's be uniform, shall we?). Thus, we'll modify things a little:
    Code:
    <select>
    <% for user in @users %>
        <option value="<%= user.id %>"><%= user.name %></option>
    <% end %>
    </select>
    Great! So, now, we have our users listed. But before we even start moving forward, let's think about this a second. Isn't the form we'll be using for the `new' template the same as the one we need for the `edit' template? Why can't we just put it in one place we'll use for both pages? Well, let's! Rails calls these types of templates which are included by others `partials'. Partials have filenames that always begine with a `_'. First of all, let's create the `form' partial for these two pages, then we'll talk about how we'll actually use it.

    The `form' partial can simply be put in a file called `_form.rhtml', in the same directory as the `new' template. Here, we'll familiarize ourselves with some of the HTML-building methods that Ruby on Rails provides to views. Specifically, we'll look at the form-building methods for now. We'll wrap each line of our form in a div with class `formLine', which we'll use later to format it a little more nicely.

    So, the first thing we need is a basic text entry box for the title. We can achieve that with fair simplicity with the [minicode]text_field[/minicode] method, which returns an appropriate field. We need to pass in two arguments: the object name and the field name -- in our case, these are `post' and `title'. This yields a text input field with the id `post[title]'. Moreover, when the form is submitted, all items with post[something] will be joined into a single hash in the parameter list with the keys being the field names and the values being the inputted values. We'll see that later. For now, the code for the field:
    HTML Code:
    <div class="formLine">
        <label for="post[title]">Title:</label><%= text_field 'post', 'title' %>
    </div>
    More or less straightforward, right? The second thing we're going to ask for is the username. This one is a little more complicated, so we'll go code first, then explain what's going on:
    HTML Code:
    <div class="formLine">
        <label for="post[user_id]">User:</label>
            <%= select 'post', 'user_id',
                    @users.collect { |usr| [ usr.name, usr.id ] } %>
    </div>
    So, once again we see the same id pattern. This time we use the [minicode]select[/minicode] method. This method takes an object name (`post'), a field name (`user_id'), and an array of arrays. This is an array that contains an array for every entry in the select box. The entry array is the display value followed by the submit value. So, if I wanted three items where the user selects among `Apple', `Orange', and `Pear', and the submitted values are `appl', `orng', and `pear', my array would be [minicode][ [ 'Apple', 'appl' ], [ 'Orange', orng' ], [ 'Pear', 'pear' ] ][/minicode].

    In order to get such an array from our users list, we use the `collect' function. As a refresher, the `collect' function iterates through all items in the collection (@users, in our case), passes each item in to a block, and puts the return value of each iteration of the block (i.e., the value of the last statement in the block) into a new array. In our case, we take each user and return an array consisting of the user's name and the user's id, which is exactly what the `select' method expects.

    Holy shininess, with a single line of code (albeit broken into two), we've got ourselves a dropdown that will at any given time display a list of users. Pretty awesome, if you ask me.

    Our final form element is a text area for the content:
    Code:
    <div class="formLine">
        <label for="post[content]">Content:</label>
            <%= text_area 'post', 'content' %>
    </div>
    Great, now we've got everything. Well, except for a submit button; we'll put this one in a div of class `formButtons':
    Code:
    <div class="formButtons">
        <%= submit_tag action %>
    </div>
    Now, we referenced this variable `action' here, but never defined it before. As it happens, we'll give it to the partial when we include it in the main templates.

    At this point, we'll include this form in the `new' template. This is extremely easy, and is done using the [minicode]render_partial[/minicode] method. This method calls the partial, and, if we give it a hash of local variables to provide, provides local variables to the partial, as well. We'll use that to pass in the action:
    Code:
    <%= start_form_tag :action => 'create' %>
    <%= render_partial 'form', { :action => 'Create' } %>
    <%= end_form_tag %>
    Have a look at your `new' page now and you'll see it looks like everything the form needs is where it should be.

    Modifying the Edit Function
    Now it's time to change the way `edit' works, too. Edit needs two pieces of information: the list of users and the post that's being edited. If you look at the URI when you click `edit' on the list page, you'll see that it looks something like [minicode]/post/edit/1[/minicode]. This `1' is the id of the post, and it will be passed in as the `id' parameter, even if it isn't explicitly labelled as such in the URI.

    The question then arises, how do we get to the parameters? Easy -- we have an @params instance variable which is just a hash of parameters indexed by their names. Due to the way Ruby works, though, we prefer to access parameters indirectly through the accessor method, so we use just [minicode]params[/minicode]. We use it the exact same way; the difference is, if at some later date the Rails developers decide to change how the whole system works, but expose the same method to us for our use, our code won't break. So, we'll write our controller's edit function in two lines this time:
    Code:
        def edit
            @users = User::find_all
            @post = Post::find_by_id params[:id]
        end
    Pretty straightforward, again. The coolest part comes when we do our edit template. As with `new', we'll call this one [minicode]edit.rhtml[/minicode], and its contents will be as follows:
    Code:
    <%= start_form_tag :action => 'update', :id => @post.id %>
    <%= render_partial 'form', { :action => 'Update' } %>
    <%= end_form_tag %>
    Notice how the only thing that changed are the action we're referring to and the action we're passing into the partial (and adding the id, obviously). Notably, the partial filled in all of its information all by itself. Why? Remember when we were filling in the partial, we gave it that object name `post'. It doesn't just use that to name the fields and pass them in when the form is submitted; it also automatically looks for an `@post' instance variable and, if it exists, pulls the initial value from that variable. You'll also notice that even the appropriate user (if it was set) is selected. Fabulous!

  5. #4
    Senior Member
    Join Date
    Jun 2005
    Location
    Atlanta, GA
    Posts
    4,146
    Member #
    10263
    Liked
    1 times
    On to Listing
    Okay, so now we've got the user information integrated into our new and edit posts pages, but what about the page where we list posts? We probably want to display what user posted it there, too, right? So, let's do that. Once again, our first step is to redefine the controller's method -- in this case, `list':
    Code:
        def list
            @posts = Post::find_all
            @columns = Post::column_names
        end
    Since all we need is the list of our posts, that's all we'll include, for now. It bears mentioning that the posts can also be paginated, but for now we'll keep it simple and display all posts in one place.

    Now that we've got our controller working, we need to create the [minicode]list.rhtml[/minicode] template. In here, all we'll do is display the list of posts in a tabular structure. Thus, our code:
    HTML Code:
    <% if @posts == nil || @posts.length == 0 %>
    
    <div class="information">There are currently no posts in the database.</div>
    
    <% else %>
    
    <table>
        <thead>
        <tr>
            <th>Title</th>
            <th>Poster</th>
            <th>Content</th>
            <th>Actions</th>
        </tr>
        </thead>
    
        <tbody>
    <%      for post in @posts %>
        <tr>
            <td><%= post.title %></td>
            <td><%= post.user.name %></td>
            <td><%= post.content %></td>
            <th><%= link_to 'Edit', :action => 'edit', :id => post.id %>
                <%= link_to 'Delete', { :action => 'destroy', :id => post },
                                      { :confirm => 'Are you sure?' } %></th>
        </tr>
    <%      end %>
        </tbody>
    </table>
    
    <% end %>
    
    <%= link_to 'Create', :action => 'new' %>
    Okay, so that was perhaps a little longer than anticipated. First, we check if @posts is nil -- which means there are no posts to display -- and give an error that says as much. Then, we display the actual posts. The first thing that's interesting is the line [minicode]post.user.name[/minicode]. Where did `user' come from if we only have a `user_id' column? Rails, upon seeing that you've set up a belongs_to relationship, actually automatically provides the `user' object for your use as an instance variable of the post object. So we can access it like anything else.

    You'll also notice that, in one case, I used `post.id' for the id, and in the other case I used `post'. This is because `post' provides the id as its string representation, so either one works -- in essence, whichever one you find clearer. I personally like adding the `.id' to the end.

    The second unfamiliar thing that we see is the [minicode]link_to[/minicode] function. link_to creates an HTML link to the specified action (it prettifies the URI for you) with the specified text. In fact, you'll notice the syntax is remarkably similar to that of form_tag. If you ever want to generate just a URI for a specific action, you can always use [minicode]url_for[/minicode], but I won't go into that for now.

    The slightly more complex form we get into for deletion bears some extra explaining. Here, we give link_to two hashes -- one that contains the URI information, and one that contains a confirmation prompt. This automatically generates a Javascript prompt that will actually ask you whether you're sure you want to delete the item before you do it. It bears mentioning that this Javascript is inlined in the code, so there's an `onclick' event handler embedded in the HTML. If you're more a fan of having your JS separated cleanly from your HTML, you're on your own for now.

    At this point, we run into a weirdness of RoR. For some reason, the hand-generated link to the scaffolded `destroy' action doesn't work very well. But that's okay, because we get to touch on [minicode]redirect_to[/minicode] by consequence. So, we'll create the `destroy' method for the Post controller:
    Code:
        def destroy
            post = Post::find_by_id( params[:id] )
            post.destroy if post != nil
            redirect_to :action => 'list'
        end
    Here we look for the post and destroy it if we found it. Then, we redirecto the `list' action, which we created a second ago. In order to use our destroy method (again, I'm not sure why we need to do this in the case of destroy in particular), we have to remove the scaffolding, so go ahead and remove the early [minicode]scaffold ost[/minicode] we have at the top of the class.

    Unfortunately, now that we've removed the scaffolding, we've also thrown away two last very useful action: create and update. If you remember, we pointed our `new' form and our `edit' form to the create and update actions, respectively. Now they don't exist, so you'll get errors when trying to use them. We can fix that with fair ease, by defining the two actions ourselves. First, the create action:
    Code:
        def create
            post = Post.new params[:post]
            post.save
    
            redirect_to :action => 'list'
        end
    Here, we create a new Post object based on the hash that gets passed in by the form (the ActiveRecord object that we extended when we created our Post model has a constructor that takes a hash and does the magic for us). Then, we save it. If the save fails, we don't do any error handling, for now, we just redirect to `list' regardless.

    The update action is similar:
    Code:
        def update
            @post = Post::find_by_id params[:id]
            if @post.update_attributes( params[:post] )
                redirect_to :action => 'list'
            else
                render :action => 'edit'
            end
        end
    Here, we find the post by id, then we try to update its attributes. If that doesn't work, we've stored the post in the @post variable, so we can just ask Rails to render the `edit' action for us, which will work as it would if we called the edit action directly. If it does work, we just redirect to the list of posts again.

    And that's it, it works! But that doesn't mean it looks like anything beyond crap. So, two more things to touch on: layouts and stylesheets.

  6. #5
    Senior Member
    Join Date
    Jun 2005
    Location
    Atlanta, GA
    Posts
    4,146
    Member #
    10263
    Liked
    1 times
    Laying It Out
    Layouts are something that wrap your templates. Basically, it's the surrounding for your template. Right now, your templates are sitting in nothing, so there are no [minicode]<html>[/minicode] tags or anything around it. To fix this, we create a [minicode]/app/views/layouts/post.rhtml[/minicode] layout:
    HTML Code:
    <html>
    <head>
        <title>Posts: <%= controller.action_name %></title>
    </head>
    
    <body>
    <h1>Posts: <%= controller.action_name %></h1>
    
    <%= @content_for_layout %>
    </body>
    </html>
    So let's go through this really quick. First of all, we have a local variable `controller' which is our controller. We can ask this controller what action we're on by calling its `action_name' method. Kind of cool. We use that to build our title, both for the titlebar and for the header. Second of all, we have the instance variable `@content_for_layout', which contains the full content for the layout. Pretty easy, huh? As you might have guessed, each controller looks for a layout that follows the convention [minicode]<controller>.rhtml[/minicode] in the [minicode]layouts[/minicode] directory.

    Stylesheeting
    Stylesheeting is the very last item on our list of introductory topics to touch on in this tutorial. In order to style pages, we need to include a stylesheet. So, we'll head back to our layout and, in the head tag, add this little number:
    Code:
        <%= stylesheet_link_tag 'general' %>
    What does that do? It includes a [minicode]<link>[/minicode] tag for a CSS stylesheet called [minicode]general.css[/minicode]. So a question then arises: where do we put the stylesheet when we actually create it? It turns out, stylesheets and javascript go into [minicode]public/[/minicode]. Stylesheets, specifically, go into [minicode]public/stylesheets[/minicode] (creative, huh?). So let's create our [minicode]general.css[/minicode] in there:
    Code:
    h1
    {
        font-size: 18pt;
        border-left: thick solid rgb(0,0,0);
        border-bottom: thick solid rgb(0,0,0);
        border-top: thick solid rgb(0,0,0);
        padding-bottom: 0.5em;
        padding-top: 0.5em;
        padding-left: 1em;
    }
    
    form
    {
        float: left;
        border: 1px dashed rgb(0,0,0);
        padding: 2px 4px;
    }
    
    form .formLine label
    {
        float: left;
        width: 200px;
    }
    
    form .formLine
    {
        border: 1px dashed rgb(0,0,0);
        padding: 2px 4px;
        margin-bottom: 1em;
    }
    
    form .formButtons
    {
        text-align: center;
    }
    
    form input, form textarea, form select
    {
        border: thin solid rgb(150,150,150);
    }
    
    table
    {
        width: 100%;
        border: 1px dashed rgb(0,0,0);
        border-collapse: collapse;
    }
    
    table td
    {
        border: 1px solid rgb(0,0,0);
        vertical-align: top;
        padding: 2px 4px;
    }
    
    table th
    {
        border: 1px dotted rgb(0,0,0);
    }
    Now, pull up the pages in the /post section and you'll see our styles have been applied perfectly well. Yeah, it's a crude style, but (1) I'm not a designer per se, and (2) this is just a quick intro tutorial, nothing fancy (yet) :-)

    So that's Rails in a whirlwind, or at least the basics. Next tutorial will consider logins, passwords (MD5, anyone?), and making the post interface use the current user as the user posting instead of giving us a dropdown. And maybe we'll work on that style a little ;-) Additional features may well also be added, but I haven't decided for sure yet, and these tutorials tend to take on a life of their own as I'm writing them :-)

    Quick final note: the basic scaffolding Rails provides is, as you might have noticed, very basic. Certain people are working on a complementary technology called Streamlined, which provides more advanced scaffolding that does nice things like automatically creating the extra relational fields when it catches has_* and belongs_* relationships defined in your models. While it hasn't been released yet, it looks interesting, so it's something to keep an eye on.

  7. #6
    Junior Member
    Join Date
    Dec 2011
    Posts
    4
    Member #
    30186
    Amazing man, thanks alot. I'm still learning rails basics (following railstutorial.org) , but once I get through that, i'm going straight to this guide.

    Thanks again.

  8. #7
    WDF Staff AlphaMare's Avatar
    Join Date
    Oct 2009
    Location
    Montreal, Canada
    Posts
    4,570
    Member #
    20277
    Liked
    878 times
    Quote Originally Posted by Perseveranze, post: 226664
    Amazing man, thanks alot. I'm still learning rails basics (following railstutorial.org) , but once I get through that, i'm going straight to this guide.

    Thanks again.
    You do realize that this thread is 5 years old? Does the information still apply?
    Good design should never say "Look at me!"
    It should say "Look at this." ~ David Craib


    http://digitalinsite.ca ~ my current site . . info@digitalinsite.ca ~ my email

    If you feel that someone's post helped you fix your problem, answered your question, or just made you feel better, feel free to "Like" their post. The "Like" link is at the bottom right of each post, along side the "reply" link. And if you are being helped here, try to help someone else - pass it on!

  9. #8
    Senior Member Kayo's Avatar
    Join Date
    Dec 2006
    Location
    Brampton Ontario
    Posts
    416
    Member #
    14523
    Liked
    39 times
    Yeah, this article is severely outdated. I never learnt Rails 2.x, but some code doesn't remotely looks like this anymore.

    Generating a Rails app
    Code:
    rails new App_Path
    No need to mkdir.

    Starting WebBrick

    Code:
    ruby script/server
    is now

    Code:
    rails server
    Or the shorter version

    Code:
    rails s
    App's Post/User model
    Code:
    rails g model Post title:string content:text user_id:integer
    rails g model User username:string name:string
    rake db:migrate
    Creating the relations is the exact same way as the older tutorial.

    Continuing
    The rest of the tutorial requires a complete rewrite. Many of the files are in different locations (hell, the file set up in rails 3.0 and 3.1 are different). Instead of ending with "*.rhtml", it now ends with "*.html.erb". Forms are completely different, and you could learn more about it here.


Remove Ads

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT -6. The time now is 11:25 AM.
Powered by vBulletin® Version 4.2.3
Copyright © 2019 vBulletin Solutions, Inc. All rights reserved.
vBulletin Skin By: PurevB.com