Re: Case for using a web framework, eg Mojolicious

[Erik Colson <..hidden..>]

Chris Travers <..hidden..> writes:

> First, before I go into this, setting some expectations.
>
> I don't think "moving to a web framework" is the right way to look at
> LedgerSMB's direction.  This way of framing things presupposes that
> LedgerSMB will always be primarily a web app, and I don't think that's a
> good idea.  We already have users who are up against the limits of what you
> can do in a web app format and eventually I would like to ensure that we
> have thick clients as well, and I don't think the "primarily a web app" is
> necessarily a good model esp when we get into higher volume transaction
> processing.
>
> So that objection is limited to how to think about the question, not
> necessarily the substance of whether or when to use a web framework going
> forward.  Those thoughts are below.

[snip]

> 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.

Hi,

This is my experience with a self-written app. It might help in your
quest ;)

I use Catalyst and wxPerl. Web app is great for reports, wxPerl is great
for input/encoding. Both share a DBIx::Schema which holds all classes
related to the database. They also share some 'Business logic' classes
which basically holds stuff like 'Check this order for validity', etc..

Also I extensively use Moose to keep a neat API for all classes. All the
wxPerl classes I use are mooseified with this in mind. For the MVC the
choice of the already Moose-compliant Catalyst seemed obvious.

Extracting the Database and Business Logic from the app to a separate
set of classes makes that I can 'glue' them to every kind of User
Interface I can think of: Catalyst/Dancer/Mojolicious/.., wxPerl/Tx/..,
console app, REST API, ...

I have met no caveats with this approach at the moment.

Best
--
erik