On Mon, Sep 3, 2012 at 8:00 AM, Ed W
<..hidden..> wrote:
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
Good to know.
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...
Perl tends to be this way generally.
- 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
I think that the key things we get from this have to do with request handling (a lot of the things we use LedgerSMB.pm and LedgerSMB/Form.pm for). This is valuable. Not sure it is possible to do with the SQL-Ledger code in a sane manner however.
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.
The key issue as far as I see it at present is that right now we have two codebases. One supports code caching reasonably well. The other (the one we inherited) is a mess. Getting it to work on Starlet was not a simple task (took me over a day of just fixing bugs and troubleshooting) and in the end if you don't fork, run, and die (i.e. each child serves one request only), after 5 runs of the chart of accounts report or 10 runs of the sales invoice screen (yes, each line entered counts), something gets corrupted and old code will just show internal server errors. I expect that until at least 1.6, running LedgerSMB on Plack or equivalent will be a bit of a specialist area. It requires knowledge of tools beyond what I'd like to require those who run the software have. I doubt these problems are specific to Plack.
Also there are a couple things that are higher priority for me at least. These are:
1) Getting a really good cross-language database interface in. We still need some work in this area. Probably during the 1.5 development time, I expect to try to build a CPAN module to do this, and then we can begin to move code over onto it in the 1.6-1.7 timeframe.
2) Getting rid of the SQL-Ledger code. This will take some time. However 1.4 and 1.5 will make large strides in this area, and 1.6 will likely continue that.
At the same time, I think moving onto someone else's code for request handling would be a good thing. I would just prefer not to invest a lot of effort in it while the codebase is in the kind of flux it is at the moment, and so far Mojolicious seems like the obvious choice. So I guess with that in mind, I would not be opposed to contributions in this regard, but I think we'd want to put them into addons/ for a release cycle before merging into mainline in order to better understand where we have problems and what needs to be done about them.
Best Wishes,
Chris Travers