With a simple Rack application written in a few lines of code I was able to start developing my example application. That’s when I realized I needed a good way to serve up all my CoffeeScript and Sass files. I was going to write a watchr script that did this, but I thought that was a bit heavy handed, and not very flexible, so I turned to Sprockets.

Sprockets recently gained a lot of attention because it is bundled in with Rails 3.1 to serve up an application’s assets. It’s a clever little library that will process your files using CoffeeScript, Sass, etc… and let you bundle them up in to a single asset by using a manifest. That was exactly what I wanted. After I spent the better part of an afternoon doing a bit of research and debugging here is the Rack configuration file I came up with:

require 'sprockets'
project_root = File.expand_path(File.dirname(__FILE__))
assets = Sprockets::Environment.new(project_root) do |env|
  env.logger = Logger.new(STDOUT)
end

assets.append_path(File.join(project_root, 'app', 'assets'))
assets.append_path(File.join(project_root, 'app', 'assets', 'javascripts'))
assets.append_path(File.join(project_root, 'app', 'assets', 'stylesheets'))

map "/assets" do
  run assets
end

map "/" do
  run lambda { |env|
    [
      200, 
      {
        'Content-Type'  => 'text/html', 
        'Cache-Control' => 'public, max-age=86400' 
      },
      File.open('public/index.html', File::RDONLY)
    ]
  }
end

That will serve

/assets/application.css

via Sprockets. The file itself will live in

<pwd>/app/assets/stylesheets/application.scss

The same goes for JavaScript files.

Hopefully this will save someone else a little of time when they’re trying to do the same thing. Enjoy!

In Java an Interface is a basically a blueprint of methods that the class who implements the Interface needs to implement. For example:

interface Bicycle {

  void changeGear(int newValue);

  void speedUp(int increment);

  void applyBrakes(int decrement);
}

public class ACMEBicycle implements Bicycle {
   
   public void changeGear(int newValue) {
     // do some work here
   }
   
   public void speedUp(int increment) {
     // do some work here
   }
   
   public void applyBrakes(int decrement) {
     // do some work here
   }

}

Here we have a Bicycle Interface that says there are three methods that need to be implemented. It is then the responsibility of the ACMEBicycle class to implement those methods. Now, an Abstract Class in Java is similar to an Interface in that it too is a blueprint of methods that the extending class may or may not need to implement. There in lies one of the differences between the two. Let’s take a look at the same example, but this time we want to implement the same behavior of all of our extending classes for the applyBrakes method:

abstract class Bicycle {
  
  abstract public void changeGear(int newValue);

  abstract public void speedUp(int increment);

  public void applyBrakes(int decrement) {
    // do some work here
  }
  
}

public class ACMEBicycle extends Bicycle {
   
   public void applyBrakes(int decrement) {
     // do some work here
   }

}

An Abstract Class is a great way to provide a mix of fully implemented methods as well as providing subclasses with a mixture of methods that need to be implemented by the extending class.

The really powerful part of all of this is two fold. First, the Java compiler will happily yell at you and fail if it finds that you haven’t implemented some of the methods that you were told you had to. Second, you can easily see the methods that you need to document right there, you can even copy/paste their definitions right into your class so you can start to fill them out.

So, how does this bring us over to Ruby? Great question. I’d like to take a few moments and explore a few ways we can get some of this power in Ruby.

Unfortunately, or fortunately depending on how you look at it (I see it as a mixed blessing), there is no compiler in Ruby, so we don’t really have a good way of having the system yell at us if we don’t implement the methods we were supposed to. But, there is still plenty we can do to help those who are implementing our classes both know what they need to implement and to find out what they haven’t implemented when their program is executing.

Here is one implementation on we can gain a bit of that functionality back in Ruby:

module AbstractInterface
  
  class InterfaceNotImplementedError < NoMethodError
  end
  
  def self.included(klass)
    klass.send(:include, AbstractInterface::Methods)
    klass.send(:extend, AbstractInterface::Methods)
  end
  
  module Methods
    
    def api_not_implemented(klass)
      caller.first.match(/in \`(.+)\'/)
      method_name = $1
      raise AbstractInterface::InterfaceNotImplementedError.new("#{klass.class.name} needs to implement '#{method_name}' for interface #{self.name}!")
    end
    
  end
  
end

class Bicycle
  include AbstractInterface
  
  # Some documentation on the change_gear method
  def change_gear(new_value)
    Bicycle.api_not_implemented(self)
  end
  
  # Some documentation on the speed_up method
  def speed_up(increment)
    Bicycle.api_not_implemented(self)
  end
  
  # Some documentation on the apply_brakes method
  def apply_brakes(decrement)
    # do some work here
  end
  
end

class AcmeBicycle < Bicycle
end

bike = AcmeBicycle.new
bike.change_gear(1) # AbstractInterface::InterfaceNotImplementedError: AcmeBicycle needs to implement 'change_gear' for interface Bicycle!

What we’ve done here is to inject a Module into our Bicycle class to give it a nice error it can raise and a little bit of help building a nice error message for the user. Then in our Bicycle class we define all the methods we want and in the ones we need the end user to define we can call the api_not_implemented method and it will raise the AbstractInterface::InterfaceNotImplementedError error for us.

We could simplify this a bit by having a nice little helper macro that we can use to build these methods, like this:

module AbstractInterface
  
  class InterfaceNotImplementedError < NoMethodError
  end
  
  def self.included(klass)
    klass.send(:include, AbstractInterface::Methods)
    klass.send(:extend, AbstractInterface::Methods)
    klass.send(:extend, AbstractInterface::ClassMethods)
  end
  
  module Methods
    
    def api_not_implemented(klass, method_name = nil)
      if method_name.nil?
        caller.first.match(/in \`(.+)\'/)
        method_name = $1
      end
      raise AbstractInterface::InterfaceNotImplementedError.new("#{klass.class.name} needs to implement '#{method_name}' for interface #{self.name}!")
    end
    
  end
  
  module ClassMethods
    
    def needs_implementation(name, *args)
      self.class_eval do
        define_method(name) do |*args|
          Bicycle.api_not_implemented(self, name)
        end
      end
    end
    
  end
  
end

class Bicycle
  include AbstractInterface
  
  needs_implementation :change_gear, :new_value
  needs_implementation :speed_up, :increment
  
  # Some documentation on the apply_brakes method
  def apply_brakes(decrement)
    # do some work here
  end
  
end

class AcmeBicycle < Bicycle
end

bike = AcmeBicycle.new
bike.change_gear(1) # AbstractInterface::InterfaceNotImplementedError: AcmeBicycle needs to implement 'change_gear' for interface Bicycle!

That approach certainly makes our code look a bit cleaner, I’m not denying that, however it has one really big flaw, at least for me anyway, it doesn’t give us a good to place to hang our documentation hat. In the previous approach we had actual methods that we could then document and that documentation would then show up in RDoc when it’s outputted. With the latter approach, however, we can document the hell out of the needs_implementation calls we have in the Bicycle class, but they won’t ever show up in the documentation. That means that users of our library have to crack open the actual code itself to see what it they are expected to implement.

Another approach we could’ve taken, which I bother to demonstrate here as I don’t think it offers a better approach is to have the needs_implementation method collect up the names of those methods and use method_missing to report that the method needs to be implemented. I mention it here only for completeness, but it definitely is not the best solution to this problem.

Finally, I would like to note that, as far as I can see, there is no way in Ruby to create a callback hook for when a class has been defined. If there was in fact such a hook we could use to it immediately notify the end user that they have forgotten to implement certain methods. Perhaps in Ruby 2.0??? That’s just pure hope on my part.

That’s it. I hope you enjoyed our brief (*cough*) look through implementing Interface and Abstract Classes in Ruby. I hope you’ve enjoyed it.

* PS, yes, I’m aware I didn’t talk about multiple vs. single inheritance in either Java or Ruby, nor did I talk about the fact that in Ruby you can’t really have Abstract Classes. I thought that was all a bit much for an already rather lengthy post as it was. Perhaps another day.

The biggest request I’ve received is from people who want to use Configatron, but they want their own instance of it, and not the global singleton instance of it. Although, I personally don’t see why you would need that, I’m a big enough man to understand that just because I don’t need it, doesn’t mean others don’t.

Last night I was reviewing the code, because I was asked this question again, and in doing so I realized that power has been there all along. It’s actually very simple. When you make a call on Kernel#configatron it returns a singleton of the Configatron class, but after that all it does is return an instance of the Configatron::Store class. So if you want your own instance of Configatron, what you really want is an instance of the Configatron::Store class, which you can do like so:

 

Well, there you go, I hope that helps. Enjoy.

Now I know that you’re just as excited about what’s coming as I am, that’s why I’ve prepared the first ever Mack screencast to demostrate these features. The screencast is a little rough around the edges, but it gets the ideas across. 

As always I’ll post more about the 0.7.0 as the release date nears. In the meantime enjoy the screencast:

The Mack Distributed Demo Screencast

Here’s the source code.

Let’s start by requiring the gem in our system. Open up your gems.rb file found in config/initializers and let’s add the gem:

require_gems do |gem|
  gem.add "pdf-writer", :version => "1.1.8", :libs => "pdf/writer"
end

Great! We’ve told Mack we want to use the ‘pdf-writer’ gem, version ’1.1.8′, and we want to automatically require the file ‘pdf/writer’. Now, let’s install the gem:

$ sudo rake gems:install

See how easy this is? We’ve installed the gem, required the libraries, now we’re ready to write our plugin.

$ rake generate:plugin name=render_pdf

That should generate a few files/folders in our vendor/plugins directory. Let’s open up vendor/plugins/render_pdf/lib/render_pdf.rb and let’s start coding.

What we want to do is create a new Mack::Rendering::Engine::Base class so that when we call render(:action) it will have a new engine to render the view file as a PDF.

We’ll examine each section in a minute, but for now, let’s type this into our render_pdf.rb file:

module Mack
  module Rendering
    module Engine
      class Pdf < Mack::Rendering::Engine::Base

        def render(io, binding)
          @_pdf = ::PDF::Writer.new
          self.view_template.instance_variable_set("@_pdf", @_pdf)
          eval(io, binding)
          @_pdf.render
        end

        def extension
          :pdfw
        end

        module ViewHelpers
          def pdf
            @_pdf
          end
        end

      end
    end
  end
end
Mack::Rendering::ViewTemplate.send(:include, Mack::Rendering::Engine::Pdf::ViewHelpers)
Mack::Rendering::Engine::Registry.register(:action, :pdf)

Ok, so on line #4 we extended Mack::Rendering::Engine::Base. This will give us access to a view methods, and will allow us to write to a very simple API. The only method you are absolutely required to implement is the render method. As we can see on line #6, we did just that.

First thing we do in the render method is instantiate a new PDF::Writer class and assign it to an instance variable. We then set that instance variable into the Mack::Rendering::ViewTemplate object we have. We do that because the way the PDF::Writer object works you need to constantly reference the instance of the writer to do your work. Example:

@_pdf.text "Hello World", :font_size => 24, :justification => :center

On line #9 we eval the io and the binding we’ve been given. The io will be contents of the view file we have disk, as a String, and the binding will be that of the Mack::Rendering::ViewTemplate object we’ve been given.

In the extension method we tell the system that are files are going to be found with the extension, pdfw. Another example of this would be the Erubis engine which declares its extension as erb.

The Mack::Rendering::Engine::Pdf::ViewHelpers module we’ve declared on line #17 is there to hide the @_pdf instance variable with a nicer pdf method. On line #27 we include this module into Mack::Rendering::ViewTemplate so it has access to it.

Finally, and most importantly, we need to register the new engine we’ve built with the system. We do that on line #28 with this bit of code:

Mack::Rendering::Engine::Registry.register(:action, :pdf)

That’s saying whenever someone calls render(:action), consider me as an engine to render that. The way the selection of which engine to use is done, is very simple. First come first serve. The engines are in an array, and the first one to have a file with its extension on disk wins. Plain and simple.

Now, let’s see all this in action. Let’s add PDF support for our ‘show’ page.

Open up views/posts/show.html.erb and add the following line:

<%= link_to("pdf", posts_show_url(:id => @post, :format => :pdf)) %>

That will give us a link that looks like ‘/posts/:id.pdf’. This will, of course, go to our PostsController and the show action. This method does not need to be altered. That’s right, you heard me. It does not need to change. Mack will handle the appropriate content-type headers for you. Just another great feature in 0.5.5.

Create a file called views/posts/show.pdf.pdfw. I know this might look a little weird, what with ‘pdf.pdfw’, but here’s the reason why. That’s break the file name down into its three parts. ‘show’ is the name of the action. ‘pdf’ is the format of the request, think also html, xml, etc… ‘pdfw’ is the engine we want to use. If we hated ourselves we could do this all in erb with a file called show.pdf.erb, but why would we want to do that?

Anyway, let’s dump this nice block of code into our show.pdf.pdfw file:

pdf.select_font "Times-Roman"
pdf.fill_color(Color::RGB::Red)
pdf.text @post.title, :font_size => 24, :justification => :center
pdf.fill_color(Color::RGB::Black)
pdf.text "by #{@post.email}", :font_size => 12, :justification => :center
pdf.with_options(:font_size => 10, :justification => :left) do |p|
  p.text "\n\n"
  p.text @post.body
  p.text "\n\n"
  p.text "Created at: #{@post.created_at}"
  p.text "Updated at: #{@post.updated_at}"
end

Since this is not a tutorial on this particular gem, I’m not going to go into what all that does. Instead, let’s just have a look at it in action.

Fire up your server:

$ rake server

And go to: http://localhost:3000. If you don’t already have a post created, create one. Now click on the show link. You should have a link on your page that says ‘pdf’ click on that link. Voila! You should be seeing a wonderfully formatted PDF right now!

Congrats! You’ve built a plugin and a new rendering engine for Mack. Now, go crazy!

The source for all this can be found at: http://github.com/markbates/mack_blog_demo/tree/master

Mack 0.3.0 introduces xml rendering support natively, so this shouldn’t be so hard. First things first, let’s fire up the app, shall we:

$ rake server

Now let’s head over to http://localhost:3000/posts. We should see our beautiful posts index page. Now let’s try to go to http://localhost:3000/posts.xml you should see something that looks like this:

Clearly, that’s not what we want, is it? I didn’t think so. The error is telling us that it’s looking for a file called index.xml.erb in the app/views/posts directory of our blog project. Obviously that file doesn’t exist.

Let’s take a second and talk about why Mack was looking for index.xml.erb. We haven’t changed anything in our controller. Our index method still looks something like this:

def index
  @posts = Post.find(:all)
end

No where in there does it mention xml. The only place xml is mentioned is on the the url itself, remember? We looked for /posts.xml. By adding .xml you’re telling Mack that you want to render, well… xml. So it goes looking for that. That’s also new in 0.3.0. The default is html, but if you append a format (.js, .xml, etc…), it will go looking for app/views/<controller_name>/<action_name>.<format>.erb and render it.

Ok, now that we understand why we’re looking for an xml file, let’s fire up our trusty text editor and create a new file called: app/views/posts/index.xml.erb. Let’s edit the file to look like this:

xml.instruct!  ml, :version=>"1.0"
xml.rss(:version => "2.0") do
  xml.channel do
    xml.title("My Mack Blog")
    xml.link(posts_index_full_url)
    xml.description("Find out about all the cool stuff happening on my blog!")
    xml.language("en-us")
    xml.copyright("Copyright Me")
    xml.pubDate(CGI.rfc1123_date(Time.now))
    xml.lastBuildDate(CGI.rfc1123_date(Time.now))
    @posts.each do |post|
      xml.entry do
        xml.title(post.title)
        xml.link(posts_show_full_url(:id => post.id))
        xml.description(post.body)
        xml.pubDate(post.created_at.strftime("%a, %d %b %Y %H:%M:%S"))
      end
    end
  end
end

Mack uses the standard builder gem library. I’m not going to go into explaining how that works, there are plenty of other tutorials and documentation that will show you that. I’m also not going to explain all the necessary pieces of an RSS feed. Instead I’ll point out in that code you’ll see we’re using the @posts instance variable that we set in the index action of our PostsController. Just like regular *.html.erb files we have access to all the instance variables from the controller, as well, helpers, etc…

So now if we go to http://localhost:3000/posts.xml we should see our RSS feed. If we did a view source we should see something that looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
 <channel>
  <title>My Mack Blog</title>
  <link>http://localhost:3000/posts</link>
  <description>Find out about all the cool stuff happening on my blog!</description>
  <language>en-us</language>
  <copyright>Copyright Me</copyright>

  <pubDate>Tue, 18 Mar 2008 17:18:05 GMT</pubDate>
  <lastBuildDate>Tue, 18 Mar 2008 17:18:05 GMT</lastBuildDate>
  <entry>
   <title>My New Post</title>
   <link>http://localhost:3000/posts/1</link>
   <description>This is my first post in my cool Mack blog!</description>

   <pubDate>Tue, 18 Mar 2008 11:58:30</pubDate>
  </entry>
 </channel>
</rss>

Awesome! All that’s really left is create one of those fancy RSS tags in the location field of our browsers that people can click and go straight to the RSS feed. Let’s do that now.

At the top of your app/views/posts/index.html.erb file add the following:

<%= rss_tag(posts_index_url(:format =>  ml)) %>

Now, refresh the page in your browser, and there you go, you should now see the little RSS button in the location bar of your browser. If you click that you should be taken to your feed.

That’s all there is to adding not only xml, but an RSS feed to your new blog.

The code for this demo can be found here.

How does Rails handle helpers?

Those of  you familiar with Rails are already familiar with this concepts. In Rails helpers are modules of code that get included into views for certain controllers, or all controllers in the case of ApplicationHelper. These helpers are meant to clean up the views and encapsulate commonly used Ruby code and keep it out of the views. In Rails 2.0 it’s easier now to include some of these helper methods into the controller, but by default, they’re not readily available.

How does Mack handle helpers?

Mack deals with helpers a little differently. Let’s start with ApplicationHelper. In Rails, ApplicationHelper gets included into all the views for every controller. This is extremely useful, and from my experience it’s the most used helper in Rails. The same is true of Mack. Regardless of which controller/view you’re in, ApplicationHelper is there to assist. This brings us to our first difference between Rails and Mack:

* ApplicationHelper is included into both the views AND the controllers.

That’s right, you no longer have to do special voodoo magic to get the contents of ApplicationHelper included into your controller, it’s right there by default, ready to go. Now, I know at this stage you’re saying, if ApplicationHelper is included into all controllers, as well as views, then aren’t the methods in there publicly accessible as actions? The answer is no. Which brings us to our next point on helpers:

* All helper public helper methods are converted to protected methods prior to be included into controllers/views.

By converting all public methods in helpers to protected methods we get around the security concerns regarding the methods becoming publicly available actions in the controllers.

Now, in Rails when you create a controller it creates a new helper module file for that controller. The idea being that you can put helpers into this module that are only available to that controller’s views.

* Mack helpers are NOT controller specific.

Mack, doesn’t do what Rails does in this respect. It’s been my personal experience that these files end up empty and just take up space on my disk. So screw em! We don’t need em.

Mack only helper concepts

Ok, so we’ve covered the basics of helpers, let’s talk about a couple of concepts that are available only in the Mack world.

Controller Helpers:

What are controller helpers? In my experience working with Rails I found that I would have ‘helper’ methods, protected or private of course, in my controllers that were meant to assist the actual actions in that controller. Two things eventually dawned on me. The first was that I’m cluttering up my controllers with all these helper methods. The second was that there should be a way to share these amongst other controllers that could probably use them as well. (Example, methods dealing with authentication)

In the Rails world I wrote a gem, controller_helpers, that helps to facilitate this. Well, being as this is the Mack world, this facility is built right in.

If you go and create a module in the app/helpers folder that’s follows the naming convention <controller_name>Helper then it will automatically be included into the appropriate controller. Two things to note here, the security model is still applied, public methods become protected methods. The second is these methods are available in that controller ONLY. They are not available in other controllers or any views within that controller.

class BlogController < Mack::Controller::Base
  before_filter :authenticate
end

module BlogControllerHelper
  def authenticate
    # do work to authenticate user here...
  end
end

As we see the controller name in the previous example was BlogController and it’s helper name was BlogControllerHelper. Now in the example we had an authenticate method in BlogControllerHelper, we realize that we also want to use that in our CommentsController as well. So we can refactor that example to look like this:

class BlogController < Mack::Controller::Base
  before_filter :authenticate
end

class CommentsController < Mack::Controller::Base
  before_filter :authenticate
end

module AuthenticationControllerHelper
  def authenticate
    # do work to authenticate user here...
  end
  include_safely_into(BlogController, CommentsController)
end

Here you can see in our new AuthenticationControllerHelper module we use the include_safely_into method. This method is documented in the RDoc for Mack, but basically what it does is includes that module into the list of Classes defined, and changes it’s public methods to protected.

Now we have included controller helpers into several different controllers. This helps to keep our controllers limited to just actions, and helps us to reuse code in other places. All very good things.

Refactoring ApplicationHelper

So, if you’re like me, your Rails ApplicationHelper module is absolutely overflowing with all sorts of bits of code. In one project I have it’s 682 lines of code! Some code does authentication like stuff, is_logged_in?, is_logged_out?, etc… some does formatting, some does other stuff. It’s a big steaming pile of unrelated code.

In Mack you can solve this problem by breaking your code out into Mack::ViewHelpers::<module_name> modules. If  you do this then that module is automatically included into all views. Modules in the Mack::ViewHelpers namespace do NOT get included into the controllers. If you want to include them into controllers you can use the include_safely_into method to achieve that goal.

Conclusion

Well, I hope you enjoyed, and are still awake, this brief overview of the way helpers work in Mack. They are different from Rails. I feel these differences are what make Mack helpers really really useful. Mack helpers do more then Rails, and these features can be not only be really powerful, but can really help to keep your code nice and DRY.

Enjoy.

$ sudo gem install mack

Great! Before we move on, make sure that the gem you installed is at LEAST version 0.1.0, otherwise, you’re not going to get very far in this tutorial. Now, let’s move on. Now let’s generate our kick ass new blog, and since we’re going to need some sort of database support for our blog, we’ll configure it to use DataMapper. If you don’t have DataMapper installed, please head over to http://datamapper.org to find out how to install it. Mack has support for ActiveRecord as well, but it’s just easier to get DataMapper going because you don’t have to deal with migrations.

$ mack my_kick_ass_blog -o data_mapper
$ cd my_kick_ass_blog

That should’ve created a whole bunch of files and folders for your blog. Now let’s generate some scaffold code for our blog:

$ rake generate:scaffold name=posts

That should’ve created even more files for you. One of those files is app/models/post.rb, let’s open that up, so we can edit it for DataMapper.

Edit the file so it looks something like this:

class Post < DataMapper::Base
  property :title, :string
  property :email, :string
  property :body, :text
  property :created_at, :datetime
  property :updated_at, :datetime

  validates_presence_of :title
  validates_presence_of :body
  validates_presence_of :email
end

Now, I’m not going to go into detail as to what that’s doing, that’s for the guys at DataMapper to explain. Before we move on to the next step, you’ll probably want to crack open config/database.yml and edit it so it the paths to your database are correct, you’ll probably also want to go to your database system and make sure that the database name you configured in your config/database.yml is created, otherwise this will be a very short trip. I’ll wait while you do that. Finished, great! Let’s move on.

We need to now open a Mack console so we can create the tables needed for our blog.

$ rake console
$ Post.table.create!
$ exit

Ok, we should now have a posts table in our new database. Isn’t life wonderful? We’re so close to showing the world how wonderful we are as developers.

Now let’s edit our views, so they look something like this:

app/views/posts/index.html.erb:

<h1>Listing posts</h1>

<table>
  <tr>
    <th>Title</th>
    <th>Body</th>
    <th>Email</th>
  </tr>

<% for post in @posts %>
  <tr>
    <td><%=post.title %></td>
    <td><%=post.body %></td>
    <td><%=post.email %></td>
    <td><%= link_to("Show", posts_show_url(:id => post.id)) %></td>
    <td><%= link_to("Edit", posts_edit_url(:id => post.id)) %></td>
    <td><%= link_to("Delete", posts_delete_url(:id => post.id), :method => :delete, :confirm => "Are you sure?") %></td>
  </tr>
<% end %>
</table>

<br />

<%= link_to("New Post", posts_new_url) %>

app/views/posts/edit.html.erb:

<h1>Edit post</h1>

<%= error_messages_for :post %>

<form action="<%= posts_update_url(:id => @post.id) %>" class="edit_post" id="edit_post" method="post">
  <input type="hidden" name="_method" value="put">
  <p>
    <b>Title</b><br />
    <input id="post_title" name="post[title]" size="30" type="text" value="<%= @post.title %>" />
  </p>

  <p>
    <b>Body</b><br />
    <textarea id="post_body" name="post[body]"><%= @post.body %></textarea>
  </p>

  <p>
    <b>Email</b><br />
    <input id="post_email" name="post[email]" size="30" type="text" value="<%= @post.email %>" />
  </p>

  <p>
    <input id="post_submit" name="commit" type="submit" value="Create" />
  </p>
</form>

<%= link_to("Back", posts_index_url) %>

app/views/posts/show.html.erb:

<p>
  <b>Title:</b>
  <%= @post.title %>
</p>

<p>
  <b>Body:</b>
  <%= @post.body %>
</p>

<p>
  <b>Email:</b>
  <%= @post.email %>
</p>

<p>
  <b>Created at:</b>
  <%= @post.created_at %>
</p>

<p>
  <b>Updated at:</b>
  <%= @post.updated_at %>
</p>

<%= link_to("Edit", posts_edit_url(:id => @post.id)) %> |
<%= link_to("Back", posts_index_url) %>

app/views/posts/new.html.erb:

<h1>New post</h1>

<%= error_messages_for :post %>

<form action="<%= posts_create_url %>" class="new_post" id="new_post" method="post">
  <p>
    <b>Title</b><br />
    <input id="post_title" name="post[title]" size="30" type="text" value="<%= @post.title %>" />
  </p>

  <p>
    <b>Body</b><br />
    <textarea id="post_body" name="post[body]"><%= @post.body %></textarea>
  </p>

  <p>
    <b>Email</b><br />
    <input id="post_email" name="post[email]" size="30" type="text" value="<%= @post.email %>" />
  </p>

  <p>
    <input id="post_submit" name="commit" type="submit" value="Create" />
  </p>
</form>

<%= link_to("Back", posts_index_url) %>

Ok, so now we’ve created our forms, and setup our index page. Let’s actually go to the site and see it all works!

First we need to start the server:

$ rake server

Now let’s head on over to http://localhost:3000/posts and see what we’ve got. You should see a page that looks something like this:

Now let’s click on that ‘New Post’ link and fill out the form:

Now, let’s hit that wonderful ‘Create’ button and see what happens!

Congrats! You just created your first blog post! Now let’s head back to http://localhost:3000/posts and see what we’ve got.

Wonderful! Now all that’s left to do is to set our home page to our posts index page. Let’s open up our config/routes.rb and edit the following line:

r.home_page "/", :controller => :default, :action => :index

so that it’s now:

r.home_page "/", :controller => :posts, :action => :index

Now all you have to do is to restart your server and Bob’s your uncle when you hit http://localhost:3000 again you should your fantastic posts index page.

This concludes our brief introductory tutorial on getting going on Mack. Obviously Mack does a lot more, and I highly encourage you to read the RDoc to find out more about what it can do.

Enjoy.

When you create your mack app you can do the following which will add ORM support to your generated app:

$ mack my_cool_mack_app -o activerecord

If you already have a mack app you can very easily add ORM support by adding the following configuration parameter to the default.yml file:

mack::orm: activerecord

And also add a database.yml file to your config directory that looks like this:

development:
  adapter: mysql
  database: my_cool_mack_app_development
  host: localhost
  username: root
  password:

test:
  adapter: mysql
  database: my_cool_mack_app_test
  host: localhost
  username: root
  password:

production:
  adapter: mysql
  database: my_cool_mack_app_production
  host: localhost
  username: root
  password: