Mojolicious Archives

My "Mojolicious Introduction" now updated for 4.0

By Joel Berger on May 17, 2013 3:22 PM under ,

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.

Continue reading »

Mojolicious 4.0 is coming soon!

By Joel Berger on May 11, 2013 3:31 PM under ,

As a newer member of the Mojolicious Core Development Team, I am more than usually excited for a Mojolicious release. This is because the next major release, version 4.0, is set to ship very soon! For those of you who don’t know, Mojolicious is a modern Perl web framework which is lightweight and easy to get started learning and using, while containing features that are cutting-edge. It’s asynchronous/non-blocking to the core, websockets work out of the box, comes with built-in DOM/JSON/UserAgent, etc etc.

Our fearless leader Sebastian Riedel (aka sri) will no doubt post a message with all the details when it ships. In the meantime, I want to share a little story of how community interaction, even at the StackOverflow level, can lead to innovation and enhancement of major projects like Mojolicious!

Continue reading »

PPI highlighted Mojolicious "quine"

By Joel Berger on February 19, 2013 11:35 PM under ,

On February 28th I will be presenting an “Introduction to Mojolicious” to the Chicago.pm meeting. If you are in the area I hope you will stop by; it won’t just be an introduction despite the name. If you are interested, here is the Meetup link.

I haven’t decided, but I might try to “self-host” the talk, writing it as a Mojolcious app! To do that I had to resurrect one of my earliest CPAN releases Mojolicious::Plugin::PPI. This module does just what the name should imply, providing syntax highlighting via PPI and PPI::HTML in a handy Mojolicious plugin.

Whether or not I decide to use this for my talk, it still is handy to have around. Here is a cute example, a simple “quine” which you can run:

#!/usr/bin/env perl

use Mojolicious::Lite;

plugin 'PPI' => { toggle_button => 1 };
get '/' => sub {
  my $self = shift;
  $self->stash( file => __FILE__ );
  $self->render('quine');
};

app->start;

__DATA__

@@ quine.html.ep
% title 'A Mojolicious "Quine"';
<!DOCTYPE html>
<html>
  <head>
    <title><%= title %></title>
    %= javascript 'ppi.js'
    %= stylesheet 'ppi.css'
  </head>
  <body>
    <h2><%= title %></h2>
    %= ppi $file
  </body>
</html>

A quine is a program that prints its source code as its output. In truth, this “quine” is really a cheater, a true quine doesn’t read itself. Still, the above example renders the source code nicely highlighted by PPI (and with some added goodies like toggleable line numbers).

Just for fun, some other Perl (cheater) quines are:

@ARGV = $0; print for <>

and 

seek DATA,0,0; print for <DATA>
__DATA__

But those outputs aren’t syntax highlighted. For a real one see the comments.

Continue reading »

A new protocol for sending files over websockets

By Joel Berger on February 11, 2013 4:58 PM under , ,

Today I’m happy to make public the work I’ve been doing to make some kind of “standard” for sending files over websockets. I call it GalileoSend because it was created for the Galileo CMS.

The protocol itself is language independent for both the client and server side, assuming that both can open a websocket connection and send JSON (as text) and binary data over it. Since communication by websocket is cheap, 2-way communication is highly encouraged throughout the transfer and positive confirmation of receipt is required.

Further, I have written a javascript client-side implementation (which could be used for any server) and a non-blocking Mojolicious server-side implemenation (which could be used for any client).

Read on (examples!) …

Continue reading »

Re-Announcing Mojolicious::Plugin::InstallablePaths

By Joel Berger on December 23, 2012 10:36 PM under ,

A few days ago, I announced the release of Mojolicious::Plugin::ModuleBuild. After some thinking I realized that without much (any?) changes it would work more generally, even with the ExtUtils::MakeMaker toolchain. Therefore I am now announcing the availability of Mojolicious::Plugin::InstallablePaths.

The general concept is that Mojolicious applications assume a certain directory structure for use locally. To make a CPAN-installable distribution out of that application one must move some directories. Further, if packaging using Module::Build, even more changes had to be applied.

Mojolicious::Plugin::InstallablePaths allows a consistent usage in all phases of development and with either build tool (EUMM or Module::Build). Hopefully this helps encourage people to think of their Mojolicious apps as candidates for CPAN and makes it easier for them to share them with the world that way!

The old module will be marked for deletion and the old blog entry will be removed as well, so don’t try to use it, its going away.

Continue reading »

A WebSocket Mojolicious/DBI Example

By Joel Berger on October 21, 2012 5:19 PM under ,

Building on my (second) example from my recent post A Simple Mojolicious/DBI Example, I thought I would take it just a little bit futher. One of my favorite features of Mojolicious is that it comes with WebSockets out of the box! In this example I show how you can take the example script and allow it to run without refreshing the window.

Continue reading »

A Simple Mojolicious/DBI Example

By Joel Berger on October 19, 2012 9:19 AM under ,

A friend of mine is learning database administration, but for the first time needs to connect it to a webapp. Having done most of his work in MS Access, he has no idea what a web framework is, nor how one would connect a database to it. To help him learn I wrote up a little application using Mojolicious and SQLite.

Continue reading »

Why People Don't Like Mojolicious

By Joel Berger on October 14, 2012 2:27 PM under

Ovid posted an interesting article about why one Perler (not himself) dislikes Mojolicious.

I have read several articles, and had several conversations about why people don’t like Mojolicious. I have been meaning to write an article about people’s dislike for Mojolicious for a while now, so I’m going to take this opportinity do so while responding to that article.

Mojolicious is Anti-CPAN

Some people don’t like it claiming that it is “anti-CPAN” and in fact this comes in two flavors. First, they believe that because a tool is available from CPAN that it should be used rather than reimplemented. Second, if one really can reimplement it better, this tool should be forked out of the project and uploaded to CPAN for everyone’s benefit.

While of course this first claim is a concern, it does seem that the Mojo devs take the task of reimplementing these tools very seriously. To the second point, I have seen this question asked at this year’s YAPC::NA and the response is, just install the whole Mojolicious package. At first you might think, “why should I install a whole web framework just to get that DOM parser?” Well, because its not that big of a framework. The Mojo devs feel that it would be a bigger maintenence burden to maintain all the modules separately then just keeping it one toolkit. I was skeptical too, its true, but it installs on my netbook in about a minute. With better hardware and parallel testing it installs on better machines in seconds!

One further argument down this line is that Mojolicious insists on using its tools internally. The person who made this argument wanted to replace Mojo::JSON with their own JSON module even while being used inside Mojolicious (both for logging and the speed of XS). They would prefer that the internal JSON engine be configurable to allow for such. While I can see this point, I also think that its the perrogative of the developer to use their own tools for internal use, that’s why they developed them after all. And hey, this is Perl, if you really want to override Mojo::JSON and replace it with your own, you can do it, there are no protected classes in Perl after all.

In fact you can use your own templating engine, you can use Plack middleware, you can serve via plackup or starman, it’s database agnostic. It uses several optional CPAN modules if you have them installed. This hardly seems anti-CPAN to me. Perhaps a different flavor of CPAN, but try it, its tasty.

The Developers are Mean/Antisocial/Stubborn/Other

Edit: After several comment have been posted, I have decided to remove my history of the developer Sebastien Riedel’s departure from the Catalyst project as I am not really qualified to write it. My understanding of the situation came primarily from reading this mailinglist entry, which seems civil enough.

Personally I have interacted with him on occasion. In my experience, the IRC channel is friendly. I have submitted patches, and yes, he and the other devs are very particular about what is included, but again, that is their perrogative. I haven’t been the subject of any meanness at all, and several of my patches have been accepted.

Back to Ovid’s Article

The reason presented in this article is a new one to me. This developer doesn’t like Mojolicious ostensibly because it allows companies to shy away from using CPAN. The company can use Mojolicious as the backbone of a webapp, but invent everything else in house.

While this is certainly an interesting realization, I would take a totally different result from it. If there are these tremendously CPAN averse companies out there, and if Mojolicious did not exist, do you really think that they would instead reach for Catalyst? I don’t think they would.

It sounds to me (and I could easily be wrong) that Ovid’s anonymous source is one of those people who are against Mojolicious for being “anti-CPAN”, and thus when they see this happen they think that Mojolicious encourages an anti-CPAN trend. I would say the opposite. Mojolicious is for these companies what the shallow end of the pool is for a young swimmer; dip a toe into CPAN and see that it feels good without fear of drowning.

Or perhaps Mojolicious is that gateway drug, the one that might bring them to CPAN. “Oh its just a little framework. You know an ORM would be nice. Well handling dates is harder than we thought, is there some CPAN-drug for that?”

Final thoughts

I’m not sure where it came from or why it started, but I see lots of people who are opposed to Mojolicious. Are there really people who hate a framework? We all love CPAN, but Mojolicious isn’t anti-CPAN, it adds to CPAN! Catalyst is great, but Mojolicious isn’t trying to kill it (or Dancer for that matter), certainly we can have more than one framework on CPAN. Go ahead use Mojo::DOM in your Dancer project! Or use JSON.pm in your side of a Mojolicious project. Someone might look at Test::Mojo (or at least its underlying Mojo::UserAgent) to test their webapp, whichever framework you use.

At times it seems almost prejudicial. There seems to be a lot of “I hate it and I won’t try it” or even worse, steering others away from Mojolicious because you have heard one of these criticisms, not because you have a real tangible concern. Again, I say “Try it!”

There’s no reason not to get along.

Continue reading »

An example using Mojo::DOM for rewriting HTML

By Joel Berger on October 4, 2012 3:25 PM under

Recently on stackoverflow, I answered a question that I thought worthy of a highlight here on the blog. In this forum we all know that one should never parse HTML with a regex, but if we agree on that, there are still many options available afterward. The question as posed was given some HTML, remove all <style> tags and contents. The question was later amended to include that he needed to also remove <style> tags with attributes (the nail in the regex coffin) and <link> tags to stylesheets.

While you could use an XML parser or an HTML tokenizer, personally I like using the Mojo::DOM parser. This is a Document-Object Model interface to your HTML and it supports CSS3 selectors, making it really flexible when you need it. The original problem is solved as easily as:

#!/usr/bin/env perl

use strict;
use warnings;

use Mojo::DOM;

my $content = <<'END';
<html>
<head> <title> Example </title> </head>
<style>
p{color: red;
background-color: #FFFF;
}
div {......
...
}
</style>
<body>
<p> hi I'm a paragraph. </p>
</body>
</html>
END

my $dom = Mojo::DOM->new( $content );
$dom->find('style')->pluck('remove');

print $dom;

The pluck method is a little confusing, but its really just a shorthand for the doing a method on each resultant object. The analogous line could be

$dom->find('style')->each(sub{ $_->remove });

which is a little more understandable but less cute. Further, to really understand that the call to find returns an instance of Mojo::Collection, a container object that has array-filtering methods as you would expect, but also can backflow back to the original DOM object. Thus when we remove the resultant tags from the collection, they are gone from the DOM object!

Now lets say that the $content variable also contained these lines

<link rel="stylesheet" type="text/css" href="$url_path/gridsorting.css">
<link rel="icon" href="somefile.jpg">

where you want to remove the first one, and not the second. You can do this in one of two ways. 

$dom->find('link')->each( sub{ $_->remove if $_->{rel} eq 'stylesheet' } );

This mechanism uses the object methods (and Mojo::DOM exposes attributes as hash keys) to remove only the link tags which have rel=stylesheet. You can however use CSS3 selectors to only find those elements, however, and since Mojo::DOM has full CSS3 selector support you can do 

$dom->find('link[rel=stylesheet]')->pluck('remove');

CSS3 selector statements can be joined with a comma to find all tags matching either selector, so we can simply include the line

$dom->find('style, link[rel=stylesheet]')->pluck('remove');

and get rid of all your offensive stylesheets in one fell swoop!

Continue reading »

Galileo and websockets

By Joel Berger on August 9, 2012 10:47 PM under , ,

While I have been on vacation, I have found a little time to add some polish to Galileo, my recently released CMS. Recent additions include a utility for writing a mostly generic configuration file and administrative popups which explain how to create new pages or add new users. The most important thing I have added though is some more setup-time documentation! Hopefully people will now find it even easier to get a Galileo-based CMS up and running.

In writing the documentation, however, I was faced with a question that I do not know the answer to: do any other plack-based or otherwise Mojolicious compatible Perl webservers (i.e. plackup, starman, twiggy etc) support websockets? While in principle a Mojolicious app can run under all of these, Galileo depends heavily on websockets, especially for content editing.

If any of you know, please comment.

I have more ideas for improvements to Galileo, but they will take a little more work than I want to put in here on vacation. In the meantime it is still very functional, go take a peak. :-)

Continue reading »
« Galileo | Main Index | Archives | Moose »

About Joel Berger

user-pic As I delve into the deeper Perl magic I like to share what I can.

More info »