Bort: Better Skeleton Applications

We’re all familiar with the rails command-line tool. It generates a Rails skeleton application with everything you need to start your Rails application–directories, configuration, even a default index page.
But the more you develop Rails applications, the more you begin to realize that some tools and gems are valuable on every project. Need a user management system? Likely restful_authentication. Rails pagination slow? Grab will_paginate. Even things like setting sessions to use the database, or using MySQL instead of sqlite3 as your database.

Enter bort. Bort is a replacement of the standard skeleton application; it includes these features (and more), already setup and configurated to work out-of-the-box. And it is a bigger box–it includes:

• RESTful Authentication, for a RESTful user-management system (registering users, logging in, etc.). Even includes the forgotten password feature!
• User Roles, to make your application users easier to manage; includes a default admin role and an admin user.
• Will Paginate, an efficient, pretty pagination plugin. Beats the standard Rails pagination by ages!
• OpenID integration, in case you want to support OpenID with your users.
• Rspec, a better way to write tests.
• Exception Notifier, to email you when your application hiccups.
• Asset Packager, which combines javascript and CSS to save download time.
• Database Sessions, MySQL DB YAML, an application-wide layout file, and no default index.html and rails.png, all of which make your life a little easier.

This is a big step up from your standard Rails skeleton. Best of all, if you don’t use half of this stuff, it won’t affect you much; and it’ll be there when you need it.

You can Grab bort from the GitHub page,
http://github.com/fudgestudios/bort

Rails "The MVC Architecture"

At the core of Rails is the Model, View, Controller architecture, usually just called MVC. MVC benefits include:

• Isolation of business logic from the user interface
• Ease of keeping code DRY
• Making it clear where different types of code belong for easier maintenance

 Models

The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.

A model represents the information (data) of the application and the rules to manipulate that data. In the case of Rails, models are primarily used for managing the rules of interaction with a corresponding database table. In most cases, each table in your database will correspond to one model in your application. The bulk of your application’s business logic will be concentrated in the models.

 Views

The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A view port typically has a one to one correspondence with a display surface and knows how to render to it.

Views represent the user interface of your application. In Rails, views are often HTML files with embedded Ruby code that perform tasks related solely to the presentation of the data. Views handle the job of providing data to the web browser or other tool that is used to make requests from your application.

Controllers

The controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and a view port to perform actions based on that input.

Controllers provide the “glue” between models and views. In Rails, controllers are responsible for processing the incoming requests from the web browser, interrogating the models for data, and passing that data on to the views for presentation.