http://www.perlmonks.org?node_id=1031336

walkingthecow has asked for the wisdom of the Perl Monks concerning the following question:

Arg, I hate to ask such a dumb question, but honestly, after a few days of really looking into Mojolicious, and playing around with it, I am still at a loss as to whether I really need it, or what it's really used for. I've read the documentation, and looked at some source code (Ashafix for one), and I still don't get it.

Basically, I am writing a web interface to some scripts that automate some system administration tasks. I could do this all quite easily in CGI, but I see this project being quite large as time progresses. All the interface does is allow the user to log in, then gives them an interface where they can select certain options, those options build commands and then the commands are run on the system. It's really quite simple, and had I went with CGI I'd probably be half done by now. However, hearing about Mojolicious framework I really wanted to give it a try; but now I am at a loss for what exactly it does... what exactly a framework is... how it differs from CGI, and so on. I was hoping that someone might give me some good examples of what they'd use Mojolicious for; what its advantages are, and so on. Basically, is it right for what I am doing?

  • Comment on What does Mojolicious do exactly and is it right for me?

Replies are listed 'Best First'.
Re: What does Mojolicious do exactly and is it right for me?
by moritz (Cardinal) on Apr 30, 2013 at 08:17 UTC

    The difference between a library (like CGI.pm) and a framework (like Mojolicious) is that you call library functions, but a framework calls your functions. That's called "inversion of control".

    If you write a CGI script, you do things like checking the URL, and if it fits certain criteria, you do stuff. If you write a web application with Mojolicious, you tell that it shall call a certain function when a certain URL is fetched.

    The idea is that this saves you from repetitive tasks like checking URLs, parameters, HTTP method (GET, POST, ...) etc.

    Basically, is it right for what I am doing?

    Probably. Follow the examples from Mojolicious::Lite, it should be quite simple.

      This is exactly what I was looking for! Thank you. I wasn't sure if the learning curve was worth it, but your post has clarified things for me and given me the motivation to continue reading the documentation and stick with Mojolicious. Thanks again.

      Just to add: After reading your post, the documentation now makes a lot more sense to me. I guess I was viewing this from a CGI viewpoint and needed a bit of a smack in my paradigm. Thanks for the smack.

        Just curious at your progress with Mojolicious 1 year on. Done anything good with it? What advise would you give "old school" CGI developers migrating to Mojolicious? Thank
Re: What does Mojolicious do exactly and is it right for me?
by Anonymous Monk on Apr 30, 2013 at 07:30 UTC

    Arg, I hate to ask such a dumb question ... how it differs from CGI, and so on. I was hoping that someone might give me some good examples of what they'd use Mojolicious for; what its advantages are, and so on. Basically, is it right for what I am doing?

    Um, go to http://mojolicio.us/, watch the slideshow, watch the video .... just like CGI.pm takes care of CGI protocol stuff for you (header/param/redirect), mojolicious takes care of the exact same things using , except instead of writing if (my $session = param('session')) { ... } elsif (my $host = param('host')) { ... you write

    get '/' => \&default; get '/cookies', \&show_cookies; post '/preview', \&do_preview; ...

    http://mojocasts.com/e1

      I second watching the mojocasts they helped me alot when i started out with mojolicious.

      I haven't used CGI much before so my ability to compare the two isn't quite there, but i find development in mojolicious very quick once you learn the lay of the land.
      -Pizentios
Re: What does Mojolicious do exactly and is it right for me?
by aitap (Curate) on Apr 30, 2013 at 07:54 UTC

    One can read "a framework" as "a set of libraries". As you can see, there are libraries for many kinds of things a developer may stumble upon in web development (for example: cookies, JSON API, templating, web server). CGI module can handle GET/POST parameters, file uploads, HTTP headers, cookies, and build HTML for itself, too, and also allows you to build complex programs, being a part of a bigger system (HTTP Server + CGI script + Templating engine + Data Storage), while Mojo already incorporates "everything" (including signed cookies for session storage, templating engine, a web server...), which makes building both simple and complex applications easier.

    Right now I'm writing a CMS for the site of a local progressive rock fan club (it's a strange thing that there are no good CMS's written in such a good web framework, or did I miss something?). A lot of things are already done for me by Mojo, signed cookies help a lot, the most hard part was the database (which I have to implement myself since Mojo is database agnostic). My suggestion is to start writing your web UI in Mojolicious::Lite and see how it goes.

      Joel Berger's Galileo might work for you. https://github.com/jberger/Galileo

        Well, Galileo is almost what I need, but I'm a little biased against JavaScript, and my browser happened not to support WebSockets (I was surprised because I thought that it was modern enough to support it). More serious issue is requirement to register users manually via admin interface instead of giving users the ability to register themselves.

        I should have probably updated my browser and added the required functionality to Galileo, but I succumbed to NIH syndrome and started everything from scratch. Shame on me.

      Honestly I never really understood the term CMS, whats the difference to a framework like Mojo?

      Multiple users with different rights to publish or ...?

        Usually, with a CMS, there come some predefined user groups and workflows.

        You have different edit pages, and not everybody is allowed to edit all kinds of items. This usually means permission groups on the actions and items.

        Usually, you have rules for publication approval of items, and maybe you can't publish your own items but have to have somebody else from a similar group approve that item.

        Also, asset management like pictures of people, and a structure that keeps things that are used together available together, like a slideshow that accompanies are something I'd expect to find in a CMS.