Chris Travers <ch...@metatrontech.com> 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 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
