Perl is well-known for its one-liners: short programs written as part of the command line invocation of the interpreter. Certainly every programmer or sysadmin has the need, from time to time, to do a quick one-off task programmatically. Such tasks can be done with a full script, to be sure, but once you get the hang of writing them, one-liners can save the time and hassle of actually doing so.

These tasks may include removing unwanted lines from files, collecting data from logs, or even a quick proof-of-concept of something that would become a script later. They can read lines in files, even multiple files, can operate on files in-place, can read from STDIN as a pipe. But while one-liners have been tools of the trade for these activities, certainly no such thing would be practical for web tasks, right?

But of course, on day 5 and day 6 of this series that we saw that we can build command line tools with your app. We have even seen how to use the eval command to run a one-liner against your app. So could we take this further?

Could we do remote data fetching and manipulation as a one-liner? Could we build an entire web application as a one-liner? Would I be asking if the answer was no?

Continue reading Day 23: One-Liners for Fun and Profit...

One of the most common misconceptions about Mojolicious is that there is a large difference between the declarative "Lite" apps that we have seen so far and large-scale structured "Full" apps. Nothing could be further from the truth. Mojolicious::Lite is a very tiny wrapper around the so-called "Full" app architecture, giving it the approachable keyword syntax.

Because it is much nicer to have concise single-file examples for documentation most of Mojolicious' documentation uses Lite syntax most of the time. It is understandable that people worry about migrating (or as we call it "growing") even once their apps would benefit from Object-Oriented structure; after all the docs seem geared towards Lite apps. However, let those fears go, the transition is easy. And once you understand it, the documentatation examples are trivial to translate.

Plus, Mojolicious comes with two forms of help when transitioning. The first is the Growing Guide which covers everything this post will but from the perspective of porting an existing application (which I won't duplicate here). The second is the inflate command which can even start you on the process by moving your templates from the data section and into their own files.

That said, in order to futher demystify things, I'm going to cover some of the differences and pull back the curtain on the Lite syntax itself.

Continue reading Day 4: Don't Fear the Full App...

One of the things we know from years of programming is that you should never hard-code anything if you don't have to. And yet far too many web application hard-code their urls, especially internal ones. But what if you didn't have to?

Each Mojolicious route has its own name which can be used to generate urls. If you don't specify one, one is generated, but you shouldn't rely on that name, give it one that is meaningful and relevant to your purposes. In lite apps, the name is the last parameter, after any defaults or callbacks. (In a full app it is an attribute, but we'll talk about those in another post).

Then when you need a url, rather than hard-coding it, use url_for or related functionality to generate a url by name, you can even pass placeholder values if needed. Let's see how it works!

Continue reading Day 3: Using Named Routes...

In Mojolicious, when processing a request and preparing a response one of the most important concepts is "the stash". Since it is a non-blocking framework, your code can't use global variables to store any state during processing. If you did and some other code were to run, it could very easily get cross-talk between requests.

The stash is the place you can store information while you process it. It is just a simple hash reference that is attached to the controller object that is processing the request. It lives and dies with that one transaction.

While you can and should use it as a scratchpad, it really is much more. The stash controls almost every aspect of the response that you generate. Let's look a little closer to see how it works

Continue reading Day 2: The Stash...

Start at the Beginning

In this Advent Calendar series, some posts will be introductory, some will be advanced, some will be on new features. Who knows what could be next? But for now let's ensure a level playing field by working out how to get started.

Continue reading Day 1: Getting Started...