A semi-official blog dedicated to the Mojolicious web framework
Over the course of this advent calendar, we have discussed the Wishlist example application several times. We used it to motivate discussions about templates, models, installable apps, and testing. In this post I want to use it somewhat differently. I would like to motivate you, the reader, into action in a few different ways.
Back on Day 9 we discussed testing and especially Test::Mojo. Today I want to just briefly talk about some practical things that can come up when testing real world applications. Once again the discussion will be motivated by the Wishlist application that we've been developing these past few days.
Thus far we have always run our applications from the local directory. That is usually the project root directory and/or the repository checkout. But did you know that with only a few changes you can make your application installable like other Perl modules?
While, you must do this if you want to upload your application to CPAN, even if you don't intend to do that, it still has benefits. You can install the application on your personal computer, especially if you want to be able to run the script while in other directories. Having an installable module also means that you can use a so-called "DarkPAN" and related tools to build yourself a local "CPAN". If you have multiple Perl modules at your company (or as part of any project) using a DarkPAN can ease integration and deployment immensely! N.B. there is even a DarkPAN tool written using Mojolicious called opan.
And hey if you needed even more more reason, it cleans up your project root directory somewhat too!
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.