#native_company# #native_desc#
#native_cta#

Smart Architectures in PHP Page 6

By Tim Perdue
on October 10, 2000

3. Portability
Certainly you don’t want to hard-code absolute urls throughout your
applicatiopn, but I’m going to take it further and say that
color picks, element names, fonts, and perhaps other options, should
be set in a config file which is included on every page. The broad
look and feel of your site should be separated out as well – obviously
you would not copy an HTML file and paste it all over the place – rather
I tend to wrap that HTML in a function call and then call the function
wherever needed.
Same goes for database password, database connection strings, etc – those
should be in the db abstraction layer.
4. Object Orientation / Functionalization
We’re not working in COBOL here – god help you if you are. So that means
we can break up processes into function calls. Each call does an atomic
action, sometimes just calling a handful of other functions and returning
the result.
A good example is checking whether a user is logged in on each page. You
could check for a cookie and query the database easily, but what if you
want to change your auth system? You’d have to go through every page of
code and change it, rather than changing one common function call in a
library. Think about that anytime you write a piece of code – if it’s something
that is going to happen more than once on your site, you should move it
into a library.

What else?

There are certainly a lot of things I’m not thinking of, so pass along
your ideas and I’ll post a follow up story in the future. In particular,
if you have written a large, complex application, I’d like to hear how
you architected it and what you’d do different if you had to start over
again.
–Tim

1
|
2
|
3
|
4
|
5
|
6