My "Mojolicious Introduction" now updated for 4.0
On Feb 28, 2013 I gave a talk to Chicago.pm about Mojolicious. I called it an introduction, but I really wanted to show some of the features that sets Mojolicious apart. Because of this, the talk moves very fast. It hits routing and responses quickly, hits testing often, on all the way to well-tested non-blocking websocket examples.
I promised to get my slides up afterwards but life (i.e. my doctoral thesis) got in the way. Now with the release of Mojolicious 4.0 I thought I would take the opportunity to right a wrong and get the slides up; so here they are: http://mojolicious-introduction.herokuapp.com/!
The talk is itself a Mojolicious app, the source of which is available from on GitHub. Not only are all the code snippets shown in the talk included, not only do they all run, but they are actually what is rendered by the talk (DRY++), so what you see is what you get! Please leave any feedback and ask any questions. I may not see the responses here, so feel free to ping me elsewhere if needed.
As I delve into the deeper Perl magic I like to share what I can.
Hi Joel
Comment re https://mojolicious-introduction.herokuapp.com/:
I feel the tendency here is to over-emphasize the power at the expense of explanations for beginners.
A few specifics:
Slide 7 line 3: { name => ‘Joel’ }: Is a hashref in this position a standard manoeuvre? Can the hashref be returned by a sub? Is this test data? Slide 13 has more but they haven’t read that yet. Yes, I know it’s a trivial question. I want beginners to get explanations rather than feel bewilderment. Is it delivered to the code the same way CGI form data is? Is it auto-inserted into the stash? Even saying ‘hello’ is the name of a template would help. ‘stashes route matches’ because…?
Slide 11: ‘Session info is signed and stored in a cookie’: Which code exactly does that? Or, is that done automatically (e.g. for every request)?
Slide 14 line 8: ‘:id’ is automatically replaced by user (web client) data.
Slide 17 line 11: In case the following code blocks. Yes I know that’s obvious to some. Line 13: Why use the stash?
Cheers Ron
Hi Ron, yes almost all of your comments are things I would have mentioned orally when giving the talk. The biggest thing I should add (which addresses most of your points) is that when a route is defined as
/:namethat matches any top-level path, for example/Ron. Then when a hashref is passed afterward, this defines defaults; your example of{ name => 'Joel }is telling the app that/should act the same as/Joel. Finally that match part of the route is stored in the stash and thus I access it via the stash.This addresses all but two of your points. The cookie handling is indeed automatic. As to the
render_lateron page 17 line 11, this prevents the controller from auto-rendering as it will try to do when nothing is rendered at the end of the method. It will then wait for therendercall which is inside the non-blocking callback.Yes, I see that these could be better explained for the web-only audience. The omissions were discussed (sometimes at length) in person. Thanks for pointing them out.
One other quick note, Chicago.pm had recently had a talk on Dancer in which the routing had been covered extensively. I piggy-backed on that to skip some of the routing tutorial, but again that doesn’t help readers here. Perhaps I can point to one of those. Then again, the Mojolicious documentation cover routing extensively, perhaps I should just add links to relevant parts of the doc (something that doesn’t work in a live presentation but may be useful here).
Cheers!