A Simple Admin for Padrino

Padrino is an excellent website framework that makes it easy to implement complex web applications in a lightweight environment. Although it’s built on Sinatra, Padrino uses a Rails-like approach when generating code, establishing an organized file structure, and implementing database functionality.

This article briefly introduces the Padrino framework and how it can be used to create a simple admin interface within a Sinatra-like environment.

A Brief Introduction to Sinatra

In a nutshell, Sinatra is a DSL (Domain-Specific Language) that processes HTTP connections. Specifically, Sinatra compares incoming user requests with entries in a list. When the first match is found, Sinatra executes the associated code and sends the results back to the user.

For example, consider an HTTP GET request arriving on this URL:

www.example.com/product/shoehorn/index.html

The DSL code within your Sinatra implementation may look like this:

get 'product/laces' do
  haml :show_laces
end

get 'product/shoehorn' do
  haml :shoehorn
end

put 'order/shoppingcart' do
  haml :cart
end

In the above code, the words get and put may look like Ruby commands, but in reality, they’re part of a filter that looks for HTTP verbs like GET, PUT, POST and DELETE.

The second filter entry in the above DSL code matches the /product/shoehorn URL, so anything between the do and its matching end will get executed, and the results will be sent back to the viewer’s browser. In this case, a reference is made to a file that contains Haml code, which Ruby will render into a web page.

Actual DSL structures are typically a lot more complex than the above example. For instance, before and after filters can be used to pre-process and post-process the results. Also, match filters can contain regular expressions as well a several other types of directives. Furthermore, the value returned to the viewer’s browser need not be HTML; in the case of a RESTful API implementation, it will consist of some JSON-encapsulated data, straight from the database, without being rendered into a view.

The bottom line with Sinatra is that the DSL implements an HTTP router. It is a very light web-processing engine that is very flexible. The downside, as you might imagine, is that the developer is forced to do everything. It can therefore be very difficult to build complex web applications. For example, it can cost days of development time to do something as simple as an administrative interface.

Padrino: Sinatra Extended

Padrino extends Sinatra by creating a simple file structure around it and providing generators to quickly get your code up and running.

For example, after installing Padrino (gem install padrino), you can create a basic web application with the following command:

padrino g project my_website -d activerecord -b

This is similar to code generation in Rails, where the system generates a group of directories and files intended to get you up and running quickly. In this case, a root directory, my_website, is created, and other files and subdirectories are stored within. Notice how the -d switch brings in the ActiveRecord ORM, and the -b switch instructs bundler to install all the dependencies.

The important subdirectories created within my_website are:

• app — where the configuration and controllers for your primary application are stored. (More on “primary” below)
• config — where files pertaining to the all internal applications are stored
• public — where images, style sheets and JavaScript files are stored

Note the use of the word “primary” above. One of the great things about Padrino is that it can package other applications into the main application. In this case, the main app directory is used to keep track of the primary my_website application, whereas information within the config directory tracks mounted applications. (We’ll see how this all works when mounting the admin application below.)

At this point, we have a minimally functional web application, albeit without any type of scaffolding that you get with Rails. To make this application actually do something, we’ll implement a minimal Sinatra-like DSL. Just to get started, we’ll put something into the bottom of the ‘my_website/app/app.rb’ file as shown below.

get '/' do
  'Hello World!'
end

Start the web server by executing the following command from within the my_website directory:

padrino start

Then we navigate to https://localhost:3000 to see the results of our genius at work. Indeed, if all worked out well, we see the classic, “Hello World!” statement within the browser.

At this point, we could continue on our merry way, writing Sinatra code and tucking it away into the my_website/app/app.rb file; however, we would be missing the point. The real beauty of Padrino lies in its ability to create applications and mount them into the framework.

The Admin Application

Let’s build a website that restricts access to a range of URL addresses. More specifically, we’ll allow all users to access the / area, but restrict access to the /admin area. In other words, everyone can access URLs starting with:

https://localhost:3000/

except for addresses starting with:

https://localhost:3000/admin

Luckily, the Padrino developers have already done most of the hard work. All we need to do is install the admin application that they created.

Keep in mind that the admin application will need to reference a database in order to store usernames and passwords. As per the information we used when generating this Padrino application, the database will use the ActiveRecord ORM and create a default sqlite adapter. (Note: We have many choices on databases and adapters.)

Install the admin application with this commande, again executed from within the my_website main directory:

padrino g admin

Note that immediately after executing this command, we now see new subdirectories:

• db — containing database migrations under the subdirectory migrate as well as some database seeding code, seeds.rb.
• admin — containing code for the installed admin application. Note that this subdirectory contains the app.rb file, defining the specifics of the protected and unprotected URL routes.
• models — containing model information

Also, notice that the apps.rb code within the config directory has been changed to include a mount point for the new admin application. By default, the mount point was changed to /admin. In other words, accesses to the location

https://localhost:3000/admin

will now be restricted to those who have admin privileges. Of course, you are free to change the mount point, if you wish. (Technically, this mount point puts the code within the /admin/app.rb file in control of access rights within the https://localhost/admin URL path.)

Additionally, you are provided a default configuration for the database migration, as appears in the db/migration/001_create_accounts.rb file shown below. The database initially tracks, among other things, the user’s email address, password, and role. The email address and password are used for login information, and the role determines the set of privileges. Initially, the role will simply be “admin,” but you can create more roles with different access rights.

class CreateAccounts < ActiveRecord::Migration
  def self.up
    create_table :accounts do |t|
      t.string :name
      t.string :surname
      t.string :email
      t.string :crypted_password
      t.string :role
      t.timestamps
    end
  end

  def self.down
    drop_table :accounts
  end
end

Run the database migration using the command:

padrino rake ar:migrate

Obviously, when you initially create the admin account, you’re going to have to specify the admin user’s email address and password. This process takes place when you seed your database, as shown below:

padrino rake seed

After executing the above command, you’ll be guided through the process of creating the admin account information, as guided by the information in the db/seeds.rb file.

If everything works correctly, you should be able to go to the location:

https://localhost:3000/admin

where you’ll get redirected to the admin/sessions/new page that provides a login form. When you login with the admin identity, you’ll get the default admin page as shown below. You can click on the accounts tab and get a list of the current account holders. You can even add more admins or change the profile of existing admins.

There is much you can do to customize your administrative interface. By implementing simple changes in the admin-related files, you can add different roles for different classes of users, and you can associate groups of these roles with different routes.

Summary

Padrino is used to implement complex code in a lightweight environment. You can begin with a basic Padrino installation, and then load applications in a modular fashion. This article uses this simple approach to create a basic Padrino application and demonstrate that its operation is very similar to Sinatra. It then installs a complete administrative interface with just a few lines of code.

Frequently Asked Questions about Simple Admin Padrino