Case for using a web framework, eg Mojolicious

[Ed W <..hidden..>]

Hi, I have some experience of using the perl web framework Mojolicious 
and whilst there are a number of very nice web frameworks, I would like 
to suggest the use of Mojolicious for LSMB.

I think you can gain a very good working knowledge of the framework if 
you watch the first couple of videos:
    http://mojocasts.com/

and checkout some of the (very decent) docs, eg here is the :Lite docs.  
Note you would *not* build LSMB using the :lite framework, but I think 
it's a compact way of quickly seeing what you get (the :Lite framework 
is more like Dancer)
    http://mojolicio.us/perldoc/Mojolicious/Lite#SYNOPSIS

The author of Mojolicious is one of the original developers of Catalyst 
and claims that he has learned from the experience... As a result, 
arguably there are faults with Mojolicious in that it tries to be 
"dependency free" compared with Catalyst being considered "module 
hell".  In fact if you check the codebase it's actually very small and 
elegant and extremely well put together.  We can all learn a lot by 
looking at the code

Mojolicious is not what I would call an MVC architecture since it 
doesn't have a strong basis for the "M", so it's really more of an 
opinionated "VC" with you left to implement the "M" however you wish...

In the case of LSMB what I can see is that the code base is already 
heavily modularised and so this almost completely becomes the "M" for 
mojo.  What you pickup for free is:

- URL Routing extracted and handled in an external and flexible way
- Strong CGI handling which abstracts all the interfacing with a web 
server. Comes with a built-in web server and can integrate with plack. 
Supports and abstracts integration with almost any web "verb", eg it's 
simple to handle GET/POST/PUT, web sockets, Event Source, etc, etc.
- Persistent cgi and route caching
- Flexible view template handling, eg responding differently to Accepts 
header: JSON/HTML/PDF etc
- Strong support for automated testing...
- Which implies: easy external automation of various tasks, define new 
"Commands" which could be used either as a form of API or to automate 
certain tasks:
    http://mojolicio.us/perldoc/Mojolicious/Commands

Of course it's not a "drop in" task in practice, but I think if you 
examine the framework you will see that at least conceptually it's a 
"drop in" for the existing code and various pieces can be migrated 
across to the services provided by Mojolicious on a piecemeal basis

Just a light recommendation.

Kind regards

Ed W