This is the conclusion of Ramaze by Example, a tutorial on web development. In Part 11: Validation and Error Handling, we added a custom error page and handlers for common user errors.

Having gone through this tutorial, you should now know about:

1. installing Ramaze
2. setting up a database schema
3. creating a base Ruby file for an application (more…)

This is part 11 of Ramaze by Example, a tutorial on web development. In Part 10: Cosmetics, I improved the look of our application.

Up to this point, we’ve been assuming users will always behave nicely and in predictable ways. As we all know, this is not a safe assumption in practice, so now we’ll add some validation and error handling to our application. I’ll introduce the changes I made somewhat in reverse order, beginning with error message display. (more…)

This is part 10 of Ramaze by Example, a tutorial on web development. In Part 9: Layout, I demonstrated how to use layouts for a consistent frontend look.

In this part, I change several things in the view layer so that the site looks a bit better. The exact details of the HTML changes are not pertinent to learning Ramaze, so I won’t go over them. You can view them yourself by doing the usual branch diff.

In this part of the tutorial, I introduce a CSS file. The reference in layout.xhtml is typical for web development in general: (more…)

This is part 9 of Ramaze by Example, a tutorial on web development. In Part 8: Deleting Tasks, we added the ability to delete tasks.

If you look at our two views, you might notice that there is some common code in both. Being good coders, we know that such unnecessary duplication is bad for maintenance and debugging, and also hinders our flexibility for future changes we might want to make.

Fortunately, Ramaze has some facilities that let you consolidate shared view code. One of these facilities is the ability to use layouts. (more…)

This is part 8 of Ramaze by Example, a tutorial on web development. In Part 7: Checking off Tasks, we added to our application the ability to check off completed tasks.

We’ll round out the functionality of our app by adding a way to delete tasks from the list. As is commonplace when building a feature into an app, we think about implementation in terms of changes to the three parts of MVC. In this case, we don’t need to make any changes to the model, because M4DBI provides us with deletion functionality for free.

Modifying the view

In the list view, we add a link for users to click on to delete tasks: (more…)

This is part 7 of Ramaze by Example, a tutorial on web development. In Part 6: Adding Tasks, we added the ability create new tasks to our application.

So now we are able to record things that need to be done; but we have no way of marking them completed!

Modifying the view

Examining the source code delta (git checkout 7-check-off-task; git diff 6-add-task), you’ll see that I added this to our index.xhtml view:

< ?r if not task.done ?>
  [#{ A(
    '&nbsp;&nbsp;',
    :href => Rs( :check_off, task.id_ )
  ) }]
< ?r end ?>

It looks a bit convoluted, but let me explain each little bit. (more…)

This is part 6 of Ramaze by Example, a tutorial on web development. In Part 5: Controller, we coded some of the core processing of our application.

So now we have a fully functional Ramaze application, with all components of MVC, each elegantly and intuitively working together with one another. However, our app’s actual functionality is very limited at the moment, so let’s build on that. We’ll add the ability to add more tasks to our todo list. (more…)

This is part 5 of Ramaze by Example, a tutorial on web development. In Part 4: View, we coded up the front end of our application.

The Controller part of the MVC pattern is the meat of your application. As much as possible, the logic, thinking, rules, and procesess of your application should be placed in controllers. A controller acts as a hub, or a central place of command. Controllers interact with models to read the state of the system, prepare variables with data that the views display, accept interactions from the user, and use models to modify the system state stored in the database. To do things by the book, you should try to keep to a minimum the Ruby code used in your views, and instead place it in controllers. (more…)

This is part 4 of Ramaze by Example, a tutorial on web development. In Part 3: Model, we coded a model class to interface with the database.

The View part of the MVC pattern is the part of your application you look at. It is essentially comprised of the static stuff: HTML and CSS. But the pretty picture is not completely inert: some parts are always the same, but other bits vary. In other words, views are templates. You setup the overall picture, and instruct Ramaze where to put the parts of the picture that change. (more…)

This is part 3 of Ramaze by Example, a tutorial on web development. In Part 2: Base Application, we wrote the main executable Ruby file for our web application.

Now we setup our models. The models are the Ruby classes that allow us to access the data in the database with Ruby objects instead of awkward things like arrays, hashes or long strings. Whatever numbers, strings, dates and things are in the database, we can read from model objects. When we change some data of a model object, a corresponding change occurs in the database. Models act as our read and write interface to the database. (more…)