For years one of my primary tasks as a Mojolicious Core Team member has been to teach Mojolicious users the ins and outs of asynchronous programming. We have championed several patterns to tame the beast and clean up async code, including continuation passing, promises and now async/await. But while promises were a noted improvement over continuation passing, it is becoming more and more clear that the async/await pattern is a paradigm shift in asynchronous programming semantics.

I personally believe that it is far and away the easiest way to do nonblocking code in modern languages. It might even reach the extent that languages and/or frameworks that do not support it are going to be in real trouble as new user will expect it to be available. With so many different languages adopting the pattern, soon many may not have even been exposed to "the old ways" at all!

Last year, during the 2018 Mojolicious Advent Calendar, I introduced my Mojo::AsyncAwait library which was intended to address the immediate need for the Mojolicious community, based on the Mojolicious core promise module Mojo::Promise. It did rely on a "controversial" module (Coro) to accomplish its task, and therefore it was not a good candidate for all users.

Meanwhile, others in the Perl community were noticing as well. Paul Evans (LeoNerd) applied for and received a grant from The Perl Foundation to build a low-level async/await mechanism for his Future promise library. As that project has successfully culminated in Future::AsyncAwait on CPAN, the Mojolicious team has been engaging with Paul on a collaboration to allow Mojo::Promise to hook directly into it.

So without futher ado, the Mojolicious Core Team is very happy to announce that as of the most recent release of Mojolicious, async/await is now a built-in framework feature!

Continue reading Announcing Core async/await...

Last week I went over how to configure and include templates. This is a pretty standard procedural solution: My current template calls another template. But what if I need to pass additional data to my layout template? Perhaps in addition to the content in my template, I also have some <meta> or <script> tags to include, or some <style> specific to this page. This would involve somehow passing data "up", or making the data available for the layout template to use. Mojolicious provides a way to do this: named content blocks.

Continue reading Named Content Blocks...

In a well-designed Model-View-Controller web application, most of the code and the development time will be in the model layer (which contains the business logic). The other two layers are meant to be as re-usable as possible. Earlier this year I discussed how to build a reusable controller for Mojolicious and how to build an inheritable controller to increase code re-use. Now, I'd like to talk about how the Mojolicious web framework provides ways to reuse, combine, and compose the view code: the stash, includes, layout templates, and named content blocks.

This week, I'll talk about how to make reusable, configurable, composable templates.

Continue reading A Reusable View Layer...

Back a few months ago I wrote about making a website for the Yancy CMS that included a basic Markdown page editor, adding a documentation viewer with the Mojolicious PODViewer plugin, and deploying a static version of the site using the Mojolicious export command. The site uses a SQLite database, which makes it very easy to set up and use the Yancy editor, but very difficult to work with the data any other way...

To solve this problem, many people have taken to writing their website as a set of static files and using a static site generator to add templates and plugins to build their website. Each page has a header section that defines some metadata about the page, like the title or the date it was posted. Instead of having each page be a row in a SQLite database, each page in a static site is a file on the filesystem!

Yancy uses "Backends" to interface with a database. To make Yancy into a static site generator, I wrote a backend that works with a flat-file database made up of YAML and Markdown files: Yancy::Backend::Static. I can use this new backend to make my Yancy documentation site even easier to edit!

Continue reading Yancy's Static Backend...

The Yancy CMS for the Mojolicious web framework currently supports three different database systems directly (and even more through the DBIx::Class ORM). As a result, when doing development, I need to have two database daemons running locally, a bunch of different environment variables to tell the tests where those databases are, and a web daemon to test the front-end.

Setting up these daemons is a pain, but I also do not want to run them all the time (to save on my laptop's battery). To me, it's easier to run a database daemon for a specific project than to try to manage all the databases I might need. But that means that every time I want to do some work on Yancy, I need to start up a bunch of things.

Since I do all my development in a terminal window, the Tmux terminal multiplexer has become an extremely useful tool. Using a shell script and Tmux, I can run a single command to set up all the databases, environment variables, and all the tabs I need to get to work quickly.

Continue reading Testing Environment With Tmux...