Home arrow PHP arrow PHP Application Development Part Two

PHP Application Development Part Two

Building on what we learned in part one, this article discusses data storage, system configuration, error handling and logging. Read on to find out how practicing the proper use of these concepts can simplify application maintenance and testing, and accelerate system debugging.

TABLE OF CONTENTS:
  1. PHP Application Development Part Two
  2. Storing Dynamic Data
  3. Error Handling
  4. Event Logging
By: David Fells
Rating: starstarstarstarstar / 36
March 08, 2005

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement

In the first article of this series, we covered some fundamental PHP application development concepts. Directory structure, file naming, and basic coding conventions were discussed. If you missed that article, you can find it here (http://www.devshed.com/c/a/PHP/PHP-Application-Development-Part-One/). In this article, we continue with the basics of PHP applications by discussing application configuration, data storage, logging and error handling. We will cover some of the basic considerations when approaching these issues and evaluate our options in regard to implementation, efficiency and maintainability.


With any application, there is a need to centralize certain information. Things like database credentials, file paths, constants, and initialization variables and options should be isolated from working code and managed in as centralized a way as possible. This allows you to alter these values in a centralized location rather than across any number of files.

Centralizing Your Configuration 

The need for centralized configuration is critical in any application, and is quite possibly the single strongest contributing factor to code maintainability. There are a number of approaches to this issue; it presents a particular problem when evaluating flexibility versus efficiency. The most typical methods for storing configuration files are with standard PHP files, XML files and INI files. Examples of a configuration file that contains only database credentials would look like the following.

 PHP
 <?php
 $settings[‘db’][‘user’] = ‘root’;
 $settings[‘db’][‘pass’] = ‘’;
 $settings[‘db’][‘host’] = ‘localhost’;
 $settings[‘db’][‘name’] = ‘test’;
 ?>

 INI
 ; settings
 [db]
 user = root
 pass =
 host = localhost
 name = test

 XML
 <settings>
  <db>
   <user>root</user>
   <pass></pass>
   <host>localhost</host>
   <name>test</name>
  </db>
 </settings>

These files are fairly straightforward, each containing a username, password, hostname and default database. Implementing the PHP file is simple enough – simply include it with the “require_once” function and no further processing is required, the “$settings” array is ready to use. The PHP version is also the least maintainable, in that it looks just like any other code and is not especially easy to read.

Using the INI file is not quite as simple, but requires only using the “parse_ini” function to retrieve the values from the file into an array. The INI file is much easier to read than the PHP version, but it could still be better. The XML version is by far the slowest, requiring at least some string matching and at most parsing the entire file. The tradeoff is evident in the semantic, easy to read nature of XML. XML files are also easily managed by a large number of programs, require the least explanation for other developers to implement, and offer the greatest portability to other modern scripting languages. This means that configuration could be shared by Java, Python, .NET, or Perl applications, for example, with ease.

Realistically, the processing time between each of these files is almost entirely negligible. However, as configuration files grow to store other information, that changes. For the most scalability and raw speed, using a PHP configuration file is the best bet, but I personally advocate the use of XML. The tradeoff for maintainability is worth it so long as you minimize the amount of XML parsed on every script page.

This is simply my opinion, and any of these options will do. In addition to using a variable to hold system settings, you have the option of storing settings in constants. Deciding what data should be stored as a constant and what data should be stored in a system variable is mostly a matter of preference, though I prefer to store system configuration in a settings array or object, and system messages and frequently used values (such as the number of seconds in a day or the maximum dimensions of uploaded images) in constants. The following list contains some common information to store in configuration files.

  1. Database credentials
  2. File paths
  3. System strings and error messages
  4. Constants for frequently used system values

Centralizing important system information is critical to the maintainability of any application and is invaluable when handing off a project to a new developer, because understanding how system data is managed is one of the first steps in understanding an unfamiliar application.



 
 
>>> More PHP Articles          >>> More By David Fells
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

PHP ARTICLES

- Hackers Compromise PHP Sites to Launch Attac...
- Red Hat, Zend Form OpenShift PaaS Alliance
- PHP IDE News
- BCD, Zend Extend PHP Partnership
- PHP FAQ Highlight
- PHP Creator Didn't Set Out to Create a Langu...
- PHP Trends Revealed in Zend Study
- PHP: Best Methods for Running Scheduled Jobs
- PHP Array Functions: array_change_key_case
- PHP array_combine Function
- PHP array_chunk Function
- PHP Closures as View Helpers: Lazy-Loading F...
- Using PHP Closures as View Helpers
- PHP File and Operating System Program Execut...
- PHP: Effects of Wrapping Code in Class Const...

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: