Getting Started With A Templating System (Ruby on Rails)

Introduction

This entry is based on the Building Browsergames entry: Getting Started With A Templating System (PHP)

Since we’re using Ruby on Rails, we’re don’t have to select a templating system, there’s one already built into Rails itself. It offers many different features to make it easy to build web pages out of parts, cache parts of pages or whole pages, etc. As with most (probably all) parts of Rails, alternatives are available to what’s built in but you’ll be satisfied with what’s already there for quite a while.

I particularly want to amplify something Luke said in the original posting. He thought a lot of developers were fans of developing their own templating systems. Wow. If that is in fact true, then you are seriously misguided if you go down that path. What’s built into Rails and the Smarty templating system Luke used for his PHP work is more than enough to get your pages done. Do not waste your time on side projects like building a templating system, use the time to improve your overall programming skills or build your game. If you do, you might be one of the few percent who actually finishes a project and others get to play it.

Using Rails Views

The design of Rails is already about separating the view which builds our HTML from the controller which connects the model to the view. So displaying the user’s name in the view is as simple as adding some code like the following to the already existing app/views/welcome/index.html.erb:

<%= render :partial => 'users/user_bar' %>
 
<% if flash[:notice] %>
  <%= h flash[:notice] %>
<% end %>
 
<h1>Welcome To The Game</h1>
 
<% if logged_in? %>
  <p>Hello, <%= @current_user.login %>!</p>
<% end %>

It’s the same as it was before except that we’ve added the section at the end that checks to see if we’re logged in and greets us if we are. Now, as long as the controller method that is called for this page sets up a @current_user variable the view will pull the login out of it and display it within the page. The restful_authentication plugin provides us with an easy to use function to check if the user is logged in or not and put the user’s info into the @current_user variable if he/she is. We’ll call that from our controller (app/controllers/welcome_controller.rb) in the index function (remember, the flow of a user’s page request always goes to the controller first to set everything up and then to the view from there).

def index
  current_user
end

If you recall from before, the old index method didn’t do anything. Now it calls the function which will fill in the @current_user variable before the index.html.erb file gets used to generate the view. At this point if you login you should find that everything works nicely.

By this point we’ve seen that the templating code (in the .html.erb files) gives us the ability to include partials pages to reuse sections of HTML, pull data from variables, and even conditionally show or not show parts of the page.

Extra Credit

  1. To learn more about the functions that restful_authentication makes available to you, look in the file lib/authenticated_system.rb. There are several functions in there to help you determine whether or not the user is logged in, restrict pages from users who aren’t yet logged in, etc.

Wish there was more?

I'm considering writing an ebook - click here.

.

John Munsch is a professional software developer with over 20 years experience. He created a series of game development sites (XPlus and DevGames.com) on his own before co-founding GameDev.net in 1999. The blog for his PBBG work is located at MadGamesLab.com.

Friday, August 29th, 2008 buildingbrowsergames, rubyonrails, templates, tutorial
  • I don't really like template system becasuse it's an overhead on your server. More than that, scripting languages like php and ruby have been designed to be simple so I'm not attracted by those templating system. I'm keen on implementing mvc like zend or cakephp but thanks for the tutorial :)

  • A lot of the templating systems available now actually pre-compile your
    templates the first time they get used - so while there is some overhead,
    that overhead is negligible after the first hit on your template - if your
    server is fast enough, the overhead from that initial hit should be barely
    noticeable.
    In my experience, programming languages are typically designed the way they
    are to increase developer productivity - Templating systems are just another
    addition to your toolbelt to increase that productivity - they aren't a
    silver bullet of any kind.

    Also, I would be wary of optimizing a little too early - your statement that
    "it's an overhead on your server" sounds like you may be prematurely jumping
    to the conclusion that your templating system is what is slowing your game
    down. As you can see by looking at the benchmarks at
    http://shootout.alioth.debian...., Ruby
    and PHP aren't what you should be using at all if you're concerned about
    performance(at least not on a 64-bit Ubuntu machine, anyway) - if you wanted
    your game to be as absolutely fast as possible on the cheapest hardware,
    you'd write it in C++.

    At the end of the day, it's your game. If you'd rather not use a templating
    system, then don't! Maintaining your code is only your responsibility, and
    you(or your team) will be the only ones who see it(or even worry about it,
    chances are). So do what you like - but know that templates come highly
    recommended.

  • amoncarter

    stumbled on this thread while looking for an education on templating systems.

    would you be able to suggest a few references of systems that you indicate come highly recommended or that pre-compile. my app is not game oriented - just a case where different websites all hosted on the same server will all use a lot of the underlying code but appear and feel different.

    I have been to the smarty website but there seems to be a lot of debate on whether that's overkill.

  • Very interesting. Thanks!

  • JohnMunsch

    Not really. The minimal amount of code added to the controller and the view there was enough to get the user object and pull out the login name.

    If you were confused by my comment that "we've seen that the templating code (in the .html.erb files) gives us the ability to include partial pages to reuse sections of HTML, pull data from variables...". That statement is true only across all of the Ruby on Rails entries I've written so far. I showed only the conditional showing and not showing parts of the page and pulling data from a variable. If you want to see the first time I used a partial you can see that in The Login Page (Ruby on Rails) Part 2 (http://buildingbrowsergames.co....

  • Flibbertigib

    Most of your article seems to have dissapeared, or fallen of the tubes or something.

blog comments powered by Disqus

About

Building Browsergames is a blog about browsergames(also known as PBBG's). It's geared towards the beginner to intermediate developer who has an interest in building their own browsergame.

Sponsors

Got Something to Say?

Send an e-mail to luke@buildingbrowsergames.com, or get in touch through Twitter at http://twitter.com/bbrowsergames