[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Case for using a web framework, eg Mojolicious
- Subject: Re: Case for using a web framework, eg Mojolicious
- From: Erik Colson <..hidden..>
- Date: Mon, 10 Sep 2012 10:48:24 +0200
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
> 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.
> 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.
This is my experience with a self-written app. It might help in your
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.