[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Case for using a web framework, eg Mojolicious
- Subject: Case for using a web framework, eg Mojolicious
- From: Ed W <..hidden..>
- Date: Mon, 03 Sep 2012 16:00:15 +0100
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:
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)
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
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.