On Tue, Sep 11, 2012 at 8:45 AM, Chris Bennett
<..hidden..> wrote:
I am also working on integrating what I have into LedgerSMB.
I am very pleased with my own interfaces for inserting, viewing and
updating my own customer, vendor and parts/assemblies data and I want to
use that to work into LSMB.
I happen to use mod_perl for that, but I don't see why that can't be
attached into LSMB from a handoff into existing web commands after
processing.
At least in my testing the new modules as of 1.3 are cached-code-safe. For customer lookups you could just use the current LedgerSMB.pm and LedgerSMB/DBObject/Company.pm (this is better structured in 1.4 however, and I'd recommend switching to that object model set instead esp. since you don't need to create your own LedgerSMB.pm objects there).
Order entry however cannot be safely cached. My approach with Plack was fork, run, and die. This could be done here as well:
fork, use OE.pm and Form.pm (use these *after* forking to be safe). Create your order, save it, report errors back to the parent process (half-duplex pipes are probably best here). Die. In this way you can still cache some of the code as needed and get significant performance benefits, but the suspect code gets included cleanly every time. I suspect Form.pm is probably cached-code-safe. I would *not* assume that OE.pm is. However you aren't including a lot of dependencies with Form.pm that you aren't including with LedgerSMB.pm and so the startup time cost of just pushing Form.pm into the post-fork portion strikes me as best.
Just to let you know. working with 1.3 on Starlet/Plack I found that the new code generally worked well in cached code contexts. However, the old code would sometimes corrupt things to the point where no old code would run anymore, and I wouldn't get any usable errors. I don't know what the problem is and I couldn't trace it. It's probably a variable scoping issue however. In particular, after five runs of displaying the chart of accounts report, or after 10 runs of showing the invoice screen, the interpreter would choke on any further old code. I got around this by setting requests per child to one, which is more or less the same approach I am suggesting above.
Best Wishes,
Chris Travers