Entry
What's the best way to start writing a PHP program?
Jul 27th, 2008 03:23
dwi h, dman, forum net tr, ha mo, Taksh Verdhan, foo bar, Dave Goose, Heini van Bergen, Philip Olson, Abdel Wahab Salah, Nathan Wallace, http://www.ttnr.org
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
goal.
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
handy.
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:
* http://google.com/Top/Computers/Programming/Languages/PHP/Tools/
* http://www.thelinuxconsultancy.co.uk/phpeditors/
* http://www.php-editors.com/
* http://www.zend.com/
* http://www.php.net/