On Wed, 2011-09-14 at 18:08 -0700, John R Pierce wrote: > On 09/14/11 6:03 PM, Thomas Dukes wrote: > >> One day, if I have time, I want to programme a complete > >> > commercial accounts systems using HTML, PHP and MySQL. Its a > >> > piece of cake to do well (meaning easily) but a little time > >> > consuming. The only difficulty I can think of is printing > >> > things locally. > > I love the challenge. I'm a hacker from way back. While this sort of stuff > > isn't humorous now days and since I've 'grown up', I understand why. Still, > > I love it!! > > an accounting system thats in plain HTML would be incredibly clunky to > use. you really want to do this in ajax/jquery or whatever so its more > interactive > > also, I'd suggest using postgresql for better data integrity, and > anything-but-php (Python?) for better webside security. ---- to each his own... I put my customer on WebERP (http://www.weberp.com) He has used in the last 15 years... Real World Accounting (since bought by Great Plains - bought by MS) Peachtree Accounting BusinessWorks Cougar Mountain Demand I handled all of the data import/transitions from one to the next with the exception of Cougar Mountain => Demand because the woman who sold him on that was a previous technical support manager for Cougar Mountain. Anyway, the one he has liked the most is the one that he didn't pay for - WebERP Before anyone gets the idea that this is all wine and roses, there are some shortcomings with WebERP, largely due to the fact that they seem to do continual releases and never really have a 'stable' version (regardless of what they say). That meant to me that I had to fix about 10-15 different things and needless to say I have no intentions of upgrading at this point (now 2+ years down the road). I have more gripes about WebERP but they are not entirely significant (with the exception that to 'extend' the featureset of WebERP, I used Ruby on Rails instead of PHP because I can do significantly better code in one quarter of the time). WebApps are clearly the future - it's hard to justify specialized server/client applications (installation, limited choice of clients, maintenance, licensing) and it seems that the future will offer 2 choices... SAAS or run your own. My own take on it... 'plain html' accounting is just fine. This company has 4 retail stores, each with a warehouse and relatively low skilled computer users entering orders. Print jobs are downloaded (or e-mailed PDF files). This is NOT a POS system (then again, neither is Quickbooks). To keep the PHP reasonably secure, it requires HTTPS and access authorization is done by LDAP authz so if you don't have a username and password on his system, you can't get the login screen. Of course the server is kept up to date. Ajax/jquery definitely ups the quality of appearance, sometimes ups the quality of the UI but definitely slows down the application and is just another demonstration of all that glitters isn't necessarily gold. As for Paul's expressed notions... It would take a fairly massive amount of man hours to produce a fully functional dual entry accounting package for widespread business use. Before you decide on an environment, you would probably want to commit to test driven development and MVC which almost invites the use of a framework (Cake/Django/RoR). Personally I am biased towards RoR but starting a large scale project in ruby, php or python without using one of the frameworks at this point would be a really poor choice. There are a number of PHP based accounting systems out there which you could probably fork but why? They all missed the boat somewhere, somehow. Craig -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.