"Paul M Foster" <paulf@xxxxxxxxxxxxxxxxx> wrote in message news:20090602134327.GK14822@xxxxxxxxxxxxxxxxxxxx > 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. So, so true. > Once done, > write code to build the database from scratch (I typically call this > "coldstart" code). With the Radicore framework you don't write code to build the database, you build your database then import the schema into the data dictionary and then have the code generated for you. > 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. As a rule of thumb for most tables you will need the same family of forms - list, search, create, read, update and delete - and the Radicore framework has patterns that will generate these for you at the touch of a button. When you want to combine 2 tables in a single form, such as "for a selected CUSTOMER show me a list of related INVOICES" or "for a selected INVOICE show me a list of related INVOICE_LINES" then there is a different pattern. Try it, and be anazed at how much code you DON'T have to write. > 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, These functions are built into Radicore, along with password encryption. You also have the choice of Single or Two Factor Authentication (via a RADIUS or LDAP server) > 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. I would advise against this as hidden fields in forms are NOT in fact invisible. The user can see what is there simply by using the browser's "View Source" button. It is even possible for the user to copy the the form, change the variables and submit it with different data. How much of a security breach could that be? I use session data for everything so that nothing is exposed on the client that does not need to be. > 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. In Radicore the screens structure files are generated using default details from the data dictionary, but these can be customised very easily. You don't need to write page controllers as there is already a pre-built page controller for each transaction pattern. You don't need to write any code to perform primary validation (such as checking that required fields are not empty, date fields contain dates, numeric fields contain numbers,etc) as the framework does this for yo automatcally using information exported from the data dictionary. > 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. Likewise I have written an entire ERP application using nothing but the Radicore framework and the Data Model Resource Book by Len Silverston. I built the PARTY, PRODUCT, ORDER, SHIPMENTS and INVENTORY databases from the shemas in the book, then used the Radicore data dictionary to generate the basic trasactions. All I had to do then was modify the table classes for the business rules, customise a few screens, and I have my working application. It is being used in real life by an online jewelery company, so it's not just an amateur product. > 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. How true. How very true. -- Tony Marston http://www.tonymarston.net http://www.radicore.org > 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
