On Sun, Mar 7, 2010 at 6:37 AM, David F. Skoll <[email protected]> wrote: > Kaare Rasmussen wrote: > >> Use Catalyst. It lets you do what you want. It only steps in where you need >> it. > > I'm not so sure about that recommendation. Having built some small > projects with Catalyst, I found it fairly large and unwieldy, quite > demanding of prerequisites and in a frustrating state of flux. > (Granted, this was about a year ago... things may have changed.) > I think the fundamental question really should be:
Given that our approach doesn't get to use some of the major parts of a framework (authentication, model), and given that the view logic is not likely to require much of a rewrite between 1.3 and 2.0, does moving to a pre-existing framework simplify or complicate our lives as developers? (Actually, I think there are just a few lines of code that will have to change in our view handling.) The answer there is "I don't know" which is why I am asking. Currently our "framework" is cobbled together pre-existing pieces, with large parts outsourced to PostgreSQL. Basically the minimal portions that need to be rewritten for 1.2 are: 1) Dispatcher script 2) Workflow scripts rewritten in 1.3 need slight alterations 3) DBObject modules need some alterations in some cases (Company.pm and Payment.pm need to be refactored) but these are more coding standards issues. 4) Refactoring of LedgerSMB.pm, LedgerSMB/DBObject.pm, and adding LedgerSMB/Request.pm 5) Contact info database needs some refactoring 6) Some changes in directory structure would be helpful 7) bin/gl.pl, LedgerSMB/GL.pm, bin/aa.pl, LedgerSMB/AA.pm, etc. Additionally, I would like to see Auth and Session handling separated into different pluggable modules. That would make it easier to implement Kerberos auth. If we go to a framework, maybe it saves us some time on #1 and #2, and parts of 4, but it means we end up having to re-implement other things. Finally, I would like to be thinking a little bit here beyond the web interface. In particular, I would like to see a framework that would serve as a basis for thick client apps as well. The major reason for this is that controlling POS hardware from a web app is difficult, kludgy, and brittle. I have one customer I support in this area and it's a pain to try to troubleshoot why pole displays sometimes lag or don't update, or the like. I would really like to build a thick client for them.... Best Wishes, Chris Travers ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
