Mojo Wonk Blog.

A semi-offical blog dedicated to the Mojolicious web framework

Day 17: The Wishlist App

Living room, Christmas tree, and presents

For today's article, I really wanted to demonstrate concepts using a practical example appliation. It is possible I let the exaxmple get away from me!

In today's article I indend to show how to use template composition techniques to produce a wishlist app. We will cover layouts, partial templates, content blocks.

The data model is admittedly rough, however I think my plan will be to make that a feature and not a bug. Today we will example concepts mostly relating to the templates, then in tomorrows post I will migrate the model from using the simplistic persistence of DBM::Deep that it uses now to Mojo::SQLite.

Continue reading Day 17: The Wishlist App...

Day 16: The Secret Life of Sessions

Pile of Scrabble tiles

As you all know, HTTP is a stateless protocol. In Mojolicious applications the session is used to maintain state between requests. These sessions are managed by the application's session manager.

During each request, the session is just another hash reference attached to the controller, in some ways like the stash, except this one persists between requests. Mojolicious does this by encoding the structure, first as JSON then Base64. It then signs the resulting string using HMAC-SHA1 and the application's secret to prevent tampering and stores it as a cookie on the response to the client.

On subsequent requests, the client sends the cookie along with the request (as cookies do). Mojolicious then checks if the document and signature validate against the secret, if so the cookie is decoded and made available again via the session method.

Two important things to note. First, though the data is safe from tampering, it isn't encrypted; a savvy user can decode the cookie and see the stored data, so don't put anything in it that shouldn't be seen. Second, this is only useful if the secret is strong and safe. If not, the client could forge a cookie that appeared to come from your application, possibly with catastrophic results! So while Mojolicious makes it easy, a little care can go a long way toward keeping your session data safe and trusted.

Continue reading Day 16: The Secret Life of Sessions...

Day 13: More About Roles

Pile of hats

Before we get ahead of ourselves, what are roles? Briefly stated, roles enable composing functionality (usually methods) into a class without without implying a change of inheritence. Said another way, roles let you specify what a class does without changing what it is. For a better description, check out Toby Inkster's article Horizontal Reuse: An Alternative to Inheritance.

An important utility of roles is that you can easily use more than one role at the same time in the same consuming class. With inheritance, especially of third-party functionality, you have to choose one set of extensions to utilize. This is because the author of the subclass establishes the inheritance. In roles, the user determines which roles to compose into the base class.

Yesterday I ended the discussion of Mojo::Base before discussing the roles support. Added in several installments between Mojolicious versions 7.40 and 7.55, this role support is one of the most recently added features in the ecosystem (along with promises, which will be covered in an upcoming article). The role handling comes from Role::Tiny which is an optional dependency in Mojolicious, but is required in order to use the functionality that I will describe.

Continue reading Day 13: More About Roles...