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:
The DSL code within your Sinatra implementation may look like this:
get 'product/laces' do
get 'product/shoehorn' do
put 'order/shoppingcart' do
In the above code, the words
put may look like Ruby commands, but in reality, they’re part of a filter that looks for HTTP verbs like
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,
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
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
Start the web server by executing the following command from within the
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:
except for addresses starting with:
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
migrateas well as some database seeding code,
admin— containing code for the installed admin application. Note that this subdirectory contains the
app.rbfile, 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
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
create_table :accounts do |t|
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
If everything works correctly, you should be able to go to the location:
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.
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.