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...

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.

Continue reading Day 17: The Wishlist App...

Writing an API can be as easy as taking the results of some database query and presenting it to the user. A more advanced one can often present the data in one of multiple formats. The user can then specify which format they want.

JSON is currently the most popular format for new APIs. XML is another common one and was certainly king before JSON hit the scene. An API might choose to make an HTML format of the data available, whether in some representation of the data or to render documentation about the API itself. Of course there are many others.

Mojolicious believes in Content Negotiation, as it is called, and supports it throughout the stack. Mojolicious makes it easy and convenient for users to pick a format they would like. Similarly it makes rendering the different formats easy on the site author, as you would expect.

Continue reading Day 10: Give the Customer What They Want...

CPAN Testers is a pretty big project with a long, storied history. At its heart is a data warehouse holding all the test reports made by people installing CPAN modules. Around that exists an ecosystem of tools and visualizations that use this data to provide useful insight into the status of CPAN distributions.

For the CPAN Testers webapp project, I needed a way to show off some pre-release tools with some context about what they are and how they might be made ready for release. I needed a "beta" website with a front page that introduced the beta projects. But, I also needed the same Mojolicious application to serve (in the future) as a production website. The front page of the production website would be completely different from the front page of the beta testing website.

To achieve this, I used Mojolicious's template variants feature.

Continue reading Day 7: Using Template Variants For a Beta Landing Page...