In these modern times, with billions of people in the world, Santa needs a modern system to keep track of his naughty/nice list. Lucky for Santa, modern Perl has a modern web framework, Mojolicious.
Yesterday we discussed templates features like layouts, partial templates, and content buffers. We motivated the discussion by introducing a fully functioning example application that tracked user's Christmas wishlists. That application did lack sophistication in the area of data storage, using DBM::Deep for quickly getting a basic persistence layer. While that worked well enough to demonstrate template functionality it was no triumph of the model layer. Indeed some very hack techniques are used, especially in manipulating wishlist items, since there was no unique record ids.
Well as promised I have created a repository for the application on Github. I have also added several tags. While development on the application may continue, those tags will remain for future readers.
The initial form of the application (as seen in yesterday's post) is tagged blog_post/dbm_deep.
You are then invited to step through the commits from that one to blog_post/full_app to follow along as I port it from a Lite to a Full app; a practical demonstration of what we saw on Day 4.
This article will briefly discuss the application as it exists in the next tag, blog_post/sqlite_model.
At this point I have replaced DBM::Deep with Mojo::SQLite, written a rudimentary model layer for it, and connected the two with the application via helpers.
Let's see how that improves the application and in the meantime, get a look at idiomatic database access in Mojolicious!
For today's article, I really wanted to demonstrate concepts using a practical example application. It is possible I let the example get away from me!
In today's article I intend 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.
Everyone has written those one-off administration or check scripts. There are probably a few cluttering your project root or bin directory right now. Those have a problem beyond just the clutter: duplication.
Programmers hate duplication because of skew. If code gets improved in one place, it is unlikely to be improved in all places, unless there is only the one. So that script you wrote a while back, the one with the database connection you hand-rolled, is that still correct?
In the previous article in this series I talked about the built-in commands available to your application.
The final command was eval.
I mentioned that when combined with predefined behaviors, the command could be great for administrative tasks.
That's true, but you need to know what to eval in order to do so.
To formalize that process, we can go one step further: defining our own commands. By doing this your application's administative behaviors can take arguemnts and provide optional switches as well as give usage messages. In this way these administative commands decouple themselves from knowledge of the application's internals and become useful to a broader set of users.