Archive for PHP

Smarty / Form validation presentation

I did a presentation at the August meeting of the Houston PHP Users Group about some of the research we did a few months ago at Alert Logic to improve our form validation code, so it’s easier to implement by making it somewhat automated and integrating it our with Smarty templates.

SlideShare | View

My Smarty Book Getting Published

Smarty PHP Template Programming and Applications

The book I have been working on for a while is finally getting published at the end of the month! The title is Smarty PHP Template Programming and Applications.

I’m very excited that it is going to be available at the end of the month, and counting the days until I get my hands on a copy myself.


For those interested, you may buy a copy at the following sites:


Eventum and its model for a Blueprint PHP Application

Harry, thanks for the praise for Eventum. This is mainly the result of my work and Bryan Alsdorf at MySQL, even though I’m no longer with MySQL AB anymore. We do agree with you on the aspects of making the page controllers as simple as possible, and also trying to let the code be as simple as possible, but still easy to maintain and change.

For some of its technical weaknesses such as the use of HTTP_GET_VARS and etc, there is a reason for this. Eventum was initially supposed to be a commercial product, and I wanted to sell commercial licenses of this application, to be then installed at the customer’s server. I tried to make the installation process as easy as possible (and it still is one of the easiest web applications to install around), and that meant working with whatever PHP configuration was available on that server. That forced me to make concessions on a few features, and that is one of them.

Anyway, thanks for the pointer, even though I’m not really involved with Eventum too much myself. I’m sure Bryan will like hearing about this.

Application Structure

I love how Richard Heyes’ Application Structure post which describes his way of layint out PHP applications is similar to my own personal structure. I have been using something very similar for a few years now, which evolved by working with PHP applications and dealing with problems and how to avoid them in the future, so it’s amusing to see two people come up with something so similar.

I basically agree with the way he separates library code from normal PHP scripts that are available to the Web, but I do things a bit different. I use the following directory structure:

application root
  |
  +- crons
  +- include
  |    +- jpgraph
  |    +- pear
  |    +- Smarty
  +- locks
  +- logs
  +- scripts
  +- setup
  +- templates
  +- templates_c
  +- webroot
       +- css
       +- images
       +- js

Explanation:

  • crons: where scripts that run off the crontab are located.
  • include: the main directory where the business logic classes are located. I also store PEAR, Smarty and Jpgraph classes here since I don’t really need to see them on the top-level directory every time I want to browse for a file. Richard couldn’t be more right about the whole idea of bundling the libraries that you depend on with your application. There’s nothing worse than waking up one day and having your code totally broken because someone upgraded PEAR to the latest release.
  • locks: scripts that run off the crontab save their lock files to avoid having two copies of the same script running at the same time. Since I cannot simply trust PHP to create a temporary file on the appropriate place, I’ll create my own directory for this.
  • logs: where assorted error logs and informative debugging logs are stored.
  • scripts: where other types of scripts are located, such as manual scripts that are available for convenience. In some cases this might not be needed.
  • setup: where configuration related files are stored. The all-mighty config.inc.php file is stored here, as well as database schema files and etc.
  • templates: where smarty template files are stored.
  • templates_c: smarty uses this directory to save compiled templates.
  • webroot: the actual web accessible directory of the application, from which PHP scripts will include the configuration file, business logic classes, Smarty and etc.

So what do I have on my config.inc.php?

< ?php
ini_set('display_errors', 1);
error_reporting(E_ALL);
set_time_limit(0);
// define the constants related to the structure
@define('APP_ROOT_PATH', '/www/htdocs/appname/');
@define('APP_PATH', APP_ROOT_PATH . 'docs/');
@define('APP_INC_PATH', APP_ROOT_PATH . 'include/');
@define('APP_PEAR_PATH', APP_INC_PATH . 'pear/');
@define('APP_SMARTY_PATH', APP_INC_PATH . 'Smarty/');
if ((stristr(PHP_OS, 'darwin')) || (!stristr(PHP_OS, 'win'))) {
    ini_set('include_path', '.:' . APP_PEAR_PATH);
} elseif (stristr(PHP_OS, 'win')) {
    ini_set('include_path', '.;' . APP_PEAR_PATH);
}
@define('APP_SETUP_PATH', APP_ROOT_PATH . 'setup/');
@define('APP_LOG_PATH', APP_ROOT_PATH . 'logs/');
@define('APP_ERROR_LOG', APP_LOG_PATH . 'errors.log');
@define('APP_LOCKS_PATH', APP_ROOT_PATH . 'locks/');
// ...
?>

Then in each PHP script on the webroot directory, I do something like this:

< ?php
include_once('../setup/config.inc.php');
include_once(APP_INC_PATH . 'class.auth.php');
include_once(APP_INC_PATH . 'class.template.php');
include_once(APP_INC_PATH . 'class.db_connection.php');
// ...
?>

And you go from there. I like Richard’s idea to use basename() to get the base directory dynamically.

Need for Marketing for PHP

Marco Tabini writes about the need of a greater marketing and business strategy in PHP to be able to compete with other technologies such as Java or .NET.

Now, my personal experience with this subject is pretty recent. I have been working for a biotech company where we develop an internal application in PHP that is used across the enterprise to manage the workflow of the research scientists and research projects. A part of this application is also used by partners that pay fees to have access to our propertory data.

This application evolved through the years, and as it is expected, the codebase got so complex and rigid that it became increasingly difficult to be flexible and implement customizations for specific installations of the application to partners. Last year the upper management of the company decided that we needed to move this whole codebase to an Oracle database (it used to be MySQL) and re-write the portions of the software that are released to partners in Java.

My point with this rant is that most of the times marketing regarding the PHP language itself, and the tools available to developers will not make any difference in the decision from a director or VP to go with Java or not. Corporations like the idea of having real corporate support and tools that have been proven as effective in the industry. My whole development team was a part of this decision to go with Java, and I can tell you that there were some good reasons to go with it.

Don’t get me wrong please, I continue to use PHP as the language of choice for most of my web application projects, such as Eventum, but there are some problems regarding the uses of PHP for commercial software. Most of them seem to be related to different behaviors of the same software in different platforms, such as the GD library having a slightly different font size for FreeBSD than for Linux (which might be related to the underlying font libraries) or the assorted bugs (#13936) that only happen in specific versions of PHP and the platform. All of these little things make the job of creating a portable codeset extremely difficult.

« Previous Page « Previous Page Next entries »