So what?

Well, you can use the global variable DATA to get the contents of what you wrote after the __END__ block. DATA is actually a File object to just that piece of text in your script.

How about a little sample to make things a little clearer?

#!/usr/bin/env ruby
%w(yaml pp).each { |dep| require dep }

obj = YAML::load(DATA)

pp obj

__END__
---
-
  name: Adam
  age: 28
  admin: true
-
  name: Maggie
  age: 28
  admin: false

So with this, I was able to embed a little bit of YAML directly into my script. I added the YAML after __END__. YAML::load will accept a File object, so I just passed it DATA and now I have a reconstituted array.

Maybe that’s not the most practical use of this information; however, Sinatra provides a really awesome use of this.  With Sinatra, you can create a whole web application that lives in one single, solitary ruby file.  Sinatra can use in-file templates.  In-file templates are added into the space after __END__ where each view file is annotated with @@view_name.

require 'rubygems'
require 'sinatra'

get '/' do
  haml :index
end

__END__

@@ layout
%html
  = yield

@@ index
%div.title Hello world!!!!!

Not bad for a useless trick!

Haml comes with a script, html2haml, which can take HTML with ERB and convert it nicely to haml. Seeing as I would have to run that command more than once, I have a little command snippet that I like to use to aid with the conversion.

$ find . -name '*erb' | \
xargs ruby -e 'ARGV.each { |i| puts "html2haml -r #{i} #{i.sub(/erb$/,"haml")}"}'

That will print out what the html2haml commands would be, it does *not* run the command. I do that step such that I can review what will be converted. If I like what’s going to be done, then I just run that command and pipe it into bash…like so

$ find . -name '*erb' | \
xargs ruby -e 'ARGV.each { |i| puts "html2haml -r #{i} #{i.sub(/erb$/,"haml")}"}' | \
bash

If you like it, it probably wouldn’t hurt storing that as a shell script somewhere :)

Why Rack

Well for one, it’s light weight. So if you want to deploy your ruby script using CGI, you can do that with Rack.

But let’s say, you want to your script to Mongrel, or WEBRick, or FCGI; you can do that too, and with very few changes to your script. That’s because Rack abstracts all the boilerplate code you would need to work with those servers and bundles it up into a nice interface for you to use.

Oh, and the code to use Rack is very easy. Here’s an example of a Rack app for you:

Examples

%w(rubygems rack haml).each { |dep| require dep }

class IndexPage
  def call(env)
    haml_engine = Haml::Engine.new(File.read('../templates/index.haml'))
    [
      200,
      { "Content-Type" => "text/html" },
      haml_engine.render(Object.new, {})
    ]
  end
end

Rack::Handler::CGI.run(IndexPage.new)

The secret behind Rack is that it will run any ruby object that has a call method and pass in the environment variables to it. In that environment variable, you will find things like HTTP_HOST, or QUERY_STRING, and the like.

If you wanted to have this script now work with WEBRick, no problem.

# Same code as above, with just a little tweak to the last line

Rack::Handler::WEBRick.run(IndexPage.new, :Port => 3000)

Tada! So now you can run a test server without worrying about setting up Apache or Lighttpd.

More Goodness

To make your life easier, Rack also comes with a set of middleware for you to use. Say you have an error in your application. Perhaps you would like to see that error formatted nicely in your browser. You can enable Rack::ShowExceptions. Perhaps you would like the code you have to be reloaded from the server whenever it changes, like when you’re developing your application, then you can use Rack::Reloader.

To use those options, you can write your Rack handler like

app = Rack::Builder.new do
  use Rack::CommonLogger  # apache-like logger
  use Rack::ShowExceptions
  use Rack::Reloader
  use Rack::ShowStatus  # create default pages for common HTTP error codes
  use Rack::Lint  #ensures all applications behave validly
  run Index.new
end
Rack::Handler::WEBRick.run(app, :Port => 3000)

There’s plenty of magic going on with Rack; A magic that does not sacrifice speed and/or flexibility. I would highly recommend giving Rack a look into the next time you want to write a simple web page.

Since you’re using CGI, you don’t _have_ to worry about setting up FCGI, or Mongrel. You can use mod_ruby if you’re using Apache or cgi with Lighttpd.

So now that servers are out of the way, time for some code.

I mentioned that you don’t have to give up HAML. So for that, I propose this little directory structure.

mysite/
   |- templates/
   `- public/

Hopefully you guessed that templates contains your HAML templates and public is the webroot for your site. Now in your public directory, create an index.rb file, and perhaps it could somewhat look like:

require 'rubygems'
require 'haml'
require 'cgi'

# A Hash for all of the variables we want to send to HAML
model = {}

# Why not get the time
model[:time] = Time.now

cgi = CGI.new

# Set up the template
haml_engine = Haml::Engine.new(File.read('../templates/index.haml'))

# Render out the HTML
cgi.out { haml_engine.render(Object.new, model) }

And there’s the tedious code. There are some interesting pieces to notice. For one, when calling cgi.out, that sends out the proper headers out to the browser *(very important)*. Also, this could probably be wrapped up into a nice function to reduce the strain of repeating one’s self.