Chris Travers wrote: > Hi all; > Catalyst fan here though it has been awhile since I did any actual coding.
I've been avoiding the discussion up to now since it was mostly heading in (my idea of) the correct direction. :-) Since I want to help and being in at the beginning, verses reverse knowledge engineering, is easier I'm chiming in now. > I have spent some time looking at Catalyst to see what would be > required to make LedgerSMB run according to current development > approaches (close to the db, etc) and the result isn't easy. > Basically, at a minimum, the following would need to be ported: > > 1) Our model Current model or _planned_ "thick" model. (Not sure what the proper term is for what is proposed, ie. everything model and generic business-rule wise that will fit and work in the database.) If you're thinking of getting the current model into Catalyst then there would be some _work_ to do! If the new model then designing and creating it will be choke point. > 2) Authentication handlers and session handlers There are some excellent tools for this that are available for "Catalyst" already. > 3) While HTML templates could use appropriate Catalyst classes, > LaTeX-based views would need to be ported.... Similarly plaint text > templates might or might not be able to be handled directly. I thought LSMB was using TT already. Should be very minor/few changes make them work. > 4) Printing directly to a printer would require subclassing existing > views.... > > I don't see this being simpler on any other framework unless it > supports the sort of stuff we're doing and that would be unusual. OK. I guess you're thinking of doing this for 1.3+. All Catalyst related comments above should be nullified for now. :-) \\||/ Rod -- > My recommendation at this point is getting stronger: Release a basic > framework ourselves and then facilitate ports of these relevant > components to other frameworks. I don't see a lot of short-term gains > from moving to an MVC framework where we have to write our own model > handlers, some of our own view handlers, and so forth. However, even > having the first two areas (session/auth/model interface) working on a > framework would open that framework up for use in creating addons, > etc..... Of course if everyone decides that one of the frameworks is > the best way to go, then we can switch the primary implementation at > that time and leave the current approach as a reference > implementation. > > Does this sound about right? > > 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 ------------------------------------------------------------------------------ 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
