Enjoying the view

module Nuts::Controllers
class Index < R '/'
def get
@time = Time.now
render :sundial
end
end
end
module Nuts::Views
def layout
html do
head do
title { "Nuts And GORP" }
end
body { self << yield }
end
end
def sundial
p "The current time is: #{@time}"
end
end

Save the file and refresh your browser window and it should show a message
like:

The current time is: Sun Jul 15 13:05:41 +0200 2007

And the window title reads “Nuts And GORP”.

Here you can see we call render :sundial from our controller. This
does exactly what it says, and renders our sundial method.
We’ve also added a special method called layout which Camping will automatically wrap our
sundial output in. If you’re familiar with HTML, you’ll see
that our view contains what looks HTML tag names. This is Markaby, which is
like writing HTML using Ruby!

Soon enough, you’ll find that you can return anything from the
controller, and it will be sent to the browser. But let’s keep that
for later and start investigating the routes.

Routes

You probably noticed the weird R '/' syntax in the previous page.
This is an uncommon feature of Ruby that is used in our favorite
microframework, to describe the routes which the controller can be accessed
on.

These routes can be very powerful, but we’re going to have look at
the simplest ones first.

Drop the < R-part and it attemps to read your mind. It
won’t always succeed, but it can simplify your application once in a
while.

Modeling the world

You can get pretty far with what you’ve learned now, and hopefully
you’ve been playing a bit off-book, but it’s time to take the
next step: Storing data.

Let’s start over again.

Camping.goes :Nuts
module Nuts::Models
class Page < Base
end
end

Obviously, this won’t do anything, since we don’t have any
controllers, but let’s rather have a look at we do have.

We have a model named Page. This means we now can store wiki pages and
retrieve them later. In fact, we can have as many models as we want. Need
one for your users and one for your blog posts? Well, I think you already
know how to do it.

If you want to migrate up to version one,
create the skeleton for the Page model,
which should be able to store,
"title" which is a string,
"content" which is a larger text,
"created_at" which is the time it was created,
"updated_at" which is the previous time it was updated.
If you want to migrate down from version one,
remove the skeleton for the Page model.

This is called a migration. Whenever you want to change or add new
models you simply add a new migration below, where you increase the version
number. All of these migrations builds upon each other like LEGO blocks.

Now we just need to tell Camping to
use our migration. Write this at the bottom of nuts.rb

def Nuts.create
Nuts::Models.create_schema
end

When The Camping Server boots up,
it will automatically call Nuts.create. You can put all kind of
startup-code here, but right now we only want to create our skeleton (or
upgrade if needed). Start The Camping Server again and observe:

This is the reversed router and it generates a URL based on a
controller. Camping ships with a
few, but very useful, helpers and you can easily add your owns. Have a look
at Camping::Helpers for how
you use these.

There’s a lot of improvements you could do here. Let me suggest:

Show when the page was created and last updated.

What happens when the page doesn’t exist?

What should the front page show?

Add a layout.

Jazz it up a bit.

The last touch

We have one major flaw in our little application. You can’t edit or
add new pages. Let’s see if we can fix that:

The core of this code lies in the new post method in the PageX
controller. When someone types an address or follows a link, they’ll
end up at the get method, but you can easily create a form which
rather sends you to the post when submitted.

There are other names you can use, but they won’t always work. So for
now, don’t be fancy and just stick to get and post.
We’ll show you how this really works later.

You might also notice that we use @input.content. The
@input-hash contains any extra parameters sent, like those in the
forms and those in the URL (/posts?page=50).

Here’s an edit-view, but you can probably do better. See if
you can integrate all of this with what you already have.