faqts : Computers : Programming : Languages : PHP

+ Search
Add Entry AlertManage Folder Edit Entry Add page to http://del.icio.us/
Did You Find This Entry Useful?

509 of 649 people (78%) answered Yes
Recently 5 of 10 people (50%) answered Yes


What's the best way to start writing a PHP program?

Jan 6th, 2009 09:28
jack uter, Taksh Verdhan, healthy man, haytham ali, Scott Mandarich, dwi h, dman, forum net tr, ha mo, foo bar, Dave Goose, Heini van Bergen, Philip Olson, Abdel Wahab Salah, Nathan Wallace, http://convonix.blogspot.com/

Design, design, design. Figure out, on paper, exactly what you want to
do.  Otherwise, you'll just be coding your way around with no real 
Plan on separating content from logic, it'll always assure cleaner, 
more maintainable code. 
Usually the apps I write are DB-related, so to use that sort of
application as an example, the first step would be nailing down, with
fairly broad scope, what sort of data needs to be stored.  This doesn't
have to mean tracking down every possible facet of information that 
will ever be pertinent, just get a good idea.  Part of the app design 
may call for it to be extensible anyway, so you don't have to know
everything ahead of time.
Once you have a good understanding of what data needs to be stored,
design your database.  Flow charts are your friend. :)  Having a
visualization of the structure of the DB will come in handy for
subsequent steps.
Now it's time for an interface between your app and the database.  I
generally avoid putting direct DB calls in my app as much as possible,
your feelings may vary.  Now that Pear is around, I've been using that
for my abstraction.  There are other options, of course.  I tend to
write three functions for each logical grouping of database fields.  
For example, if it were a web log, there may be some groups of fields 
such as Users, Entries, Categories, and Polls.  For these, I would 
write getEntry, setEntry, deleteEntry, getUser, setUser, deleteUser, 
and so on.  I may not find a need to use all these functions, but 
being able to assume they're there if I come to that point later on is 
Usually for me the next step is the administrative portion of the app.
The screens involved in (using the web log example) logging in as a
user, posting a new entry, and perhaps adding a poll.  The admin
interface tends to have three components to it: The navigation, the
forms for input, and the code for validating/DB access.  Since
separating content from code is good, I tend to have these three
components thoroughly separated.
The navigation can be done any number of ways, I tend to use button 
menu screens (You log in, get a Main Menu, click on 'Manage Users', 
get a User Menu, click on 'Add User', get an Add User form, etc.)  For 
form input, I like to make my forms dual-purpose.  That is, the same 
file can be used for adding a user as it can for editing.  It's a 
simple process, and it's handy for keeping maintenance hassles low.  
These forms, of course, submit their data to the code that does 
validation and DB access.
So that's the admin side, more or less.  Once that's all in place, the
only thing left to do is the actual web pages that people will be 
using.  I'm no designer, so I don't relish this part.  Thankfully, I 
work with people who are designers, so often while I'm coding the 
admin side, they're doing up the templates for the site.  Then 
integration is just a matter of plugging in snippits of PHP to extract 
a value here, interate through some DB fields there..  Pretty soon, 
it's all done.  (Okay, so it usually doesn't seen like 'pretty soon' 
when it actually gets finished).
Okay, I'll stop rambling now.
Also, choosing a PHP aware editor helps, and PHP developmental tools.  
Zend.com is a company dedicated to PHP and offers many great products 
and tools, check them out.  As far as PHP friendly text editors and 
related tools go, check out these links: