On Tue, Jun 02, 2009 at 02:50:36PM +1000, Angus Mann wrote: > Hi all. > > I'm working on a PHP project for my own personal business use. It will > handle billing and invoices as well as payments and time management, > bookings, appointments and a few more. I may add things like personal > messaging between the various users and a customer login to check on the > progress of their accounts. > > It is a big project and will probably take a year or so to complete in my > spare time. > > I have made a couple of starts but I have no experience in creating such > large applications and I find I often end up with spaghetti code. I've > tried > using session variables to keep track of where and what the program is > doing > but there are so many permuations and combinations I found myself writing > endless streams of if's, and's and or's just to figure out what page to > display. > > The code is not the probblem for me...it's the flow and organization of the > code. > > Can anybody point me to a good book or tutorial that lays down the > principles and gives some suggestions for integrating the many subroutines > of a large application? I want to make the code readable and logical in its > flow, and avoid repetition of code segments. Other responders have cautioned you to use a framework (my vote is CodeIgniter) to save time. You can do this, but I've done what you're doing, without a framework, and it's not that hard. The first and most important point is to get the database right, as pointed out elsewhere. Think long and hard about this one. Once done, write code to build the database from scratch (I typically call this "coldstart" code). In general, your screens will involve adding, editing, deleting, searching and listing records from your database. Consider doing an outline of what screens you'll need. Take the various items you deal with, like customers, invoices, jobs, etc., and determine if you want to create add, edit, delete, search and listing screens for each. Put everthing you might need in your outline. You may find, in the process of doing all this, that you need to rethink parts of your database. Think about security, as in passwords, usernames, etc. Put in your outline some screens for logging in and logging out, and add whatever infrastructure you need to your database. One point here: The only time I use session variables is in this area. Otherwise, you shouldn't need them for keeping track of things. Let me expand on that. When you have a form (which is what most of your application will be composed of), it will return all the data you need to process it. You process it, and proceed to a menu or somesuch to tackle the next task. If, for some reason, you need to track data across invocations of screens, you can typically do it with hidden fields in your forms. You'll typically need a template which contains the HTML stuff that needs to fit around your individual screens, and which won't change from screen to screen. Inside that template, you can include a call to whatever "view" file is needed for that screen. Something like: <?php include($viewfile); ?> You can build each screen however you want, but it's really just form work-- a field for name, a field for address, etc. At the bottom, a submit button. Each form will be driven by a "controller" which sets everything up for the view file. And it will also process the results for the view (once the user hits the "submit" button). It will hand off results to the "model" file, which knows all about the database, so the model file (class) can vet and store the data properly. That's the way I've done this, through two iterations of my applications. My internal system handles customers, invoices, payables, statistics, mailing lists, payroll, pricing, a calendar, and several other areas for my business. Others will doubtless argue about how I've done this. There are about as many opinions about how all this should be done as there are developers. I'm just giving you advice on how I've done it. Feel free to ask other questions. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
