PHPLarge :: FuzzyOffice :: 002 - Starting Small
Last updated: 8/16/2002; 7:54:39 AM
The FuzzyBlog!

Marketing 101. Consulting 101. PHP Consulting. Random geeky stuff. I Blog Therefore I Am.

PHPLarge :: FuzzyOffice :: 002 - Starting Small

Note: Bear in mind that I'm writing some kinda complex things here without a technical reviewer.  It's like flying without a net.  You know where to email me when I'm wrong but be kind.

I'd love to tell you that this story contains all the FuzzyOffice code.  I can't.  I can't even tell you that this script contains most of the FuzzyOffice code.  It doesn't.  (And the next statement won't surprise you then).  I can't even tell you that this script contains _ANY_ FuzzyOffice code.  It doesn't.  But it does contain code.  Of that you can be certain.

Let me explain.

FuzzyOffice is now the biggest single PHP application I've written.  It's up to 27 + modules all at various levels of functionality, almost all of them able to store and retrieve data.  More importantly and worse for writing about.  They're all pretty much architected a little bit differently as I've "adapted" my style to fit the needs of the application.  And, if you think "adapted" means "screwed up in the early stages" that would be correct Mr. Spock.  You can now pass go and collect your obligatory 200 bars of Latinum. 

So, when you know that they code you want to document isn't quite right yet and you honestly can't face rewriting it again – at the time you want to blog about it, what do you do?  What do you do?  You start small.

Simple.  You Make YAW (yet another website) that illustrates the approach to coding you are taking and is deliberately simple yet real.  That's starting small.  Once this example is out I should have had time to improve the coding on some of my base modules and be ready to show them.  And, since I'm using the same coding approach for those scripts as I illustrate here, there is indeed frothy goodness to be learned.

So, without (much) further ado, I give you …

(yeah it actually exists and kinda even works)

Problem: I want to read blogs about php.  I can't find them.  I know they're out there but where?

Solution: A website which is a registry of php related blogs.

Comment: Along the way document the source code and showcase core FuzzyOffice concepts including:

  • An event driven coding model that even applies to home pages
  • A template driven layout model that even applies to homepages
  • Network I/O (input / output) with Snoopy

Event Driven PHP Coding

Disclaimer: I am by no means taking credit for this style of coding.  I'm not sure if I picked it up somewhere or invented it (like many things I do, I woke up at 3 am one morning with that classic "thunderbolt from god" experience when it was all just so clear to me).  I'm also not saying it's perfect at all.  I (probably) wouldn't use this for a high performance website with huge traffic.  I originally thought that it seems best for websites that are really software applications.  Now I'm starting to use it for content sites also.  It works for me; perhaps for you, perhaps not.  Anyway …

PHP has a wonderful feature where you can readily mix code and HTML willy nilly (that means "all together and at random").  For me at least?  It's not the right approach.  It's a very, very fast way to develop – that I will admit.  It's also, at least for me, a maintenance nightmare.  Here's what I like:

  • Code separate from HTML
  • One PHP source file that contains pretty much all of the "module" level application logic
  • Clear logic flow
  • The ability to fork tasks based on skills – give a good designer like my partner Gretchen the task of the HTML and give me the real coding
  • The ability to use real design tools for HTML
  • The ability to translate and localize sites easily; the world isn't just English you know
  • The ability for an editor to review AND repair text in a site without having to grovel through web pages

When you intermix HTML and PHP freely, this goes out the window and you're left with just plain lots of PHP files that only a real coder can deal with.  That's great for the php coder (it keeps him employed) and not so great for the project or organization.  The combination of event driven coding and template driven layout solves most of this.  (What I mentioned with respect to an editor requires an additional step of abstraction that we'll cover in the next story).

So, what is event driven coding you ask?  I'm finding that increasingly even my content pages have web forms inside them.  And whenever there is a web form, there also needs to be a script to handle the "events" that generates.  Of course this quickly leads to this mess:

  • HTML page with N forms where N is a positive integer NOT less than 1 but often greater (search form, email this to a friend form, comment form)
  • PHP script for processing the search form
  • PHP script for processing the email this form
  • PHP script for processing the comment form

That's a mess!  Here's how I handle it:

switch ($action ) { 



Near the top of any of my event driven scripts is this block.  All of my forms have a hidden variable called action which is handled by one or more cases within this switch statement.  Here's an example form from which is part of the index.php url:

<FORM name=add action=index.php method=post>

<input type=hidden name=action value=add>

I then define a function to handle that action and I'm pretty much done.  When the page is just being displayed, the default case is called (since $action is null) and then the page's display routine is called.  More on that routine in the 2nd section following but first something about how I code …

Coding Conventions

Every programmer defines his or her own coding conventions as they develop.  And some can be fairly idiosyncratic (or weird).  I'm no different.  Here are some of the conventions you'll see in my stuff:

Header Block at the Beginning

Two Character Indenting with Spaces

All Include Statements at the Top

Global "Meta" Variables Following Include

Switch Statement after Globals

Function Definitions with LOTS of white space between them

SQL statements Defined on Entirely Separate Lines of Their Own

Most of this is pretty basic so I don't need to describe it further.  Two things stand out though.  "Lots of white space" means that I actually have 10 or 15 blank lines between different functions.  Why?  I'm not a huge subroutine person in PHP so my functions tend to be large (that's bad I know; it's a work in progress).  With lots of white space between functions, it's very apparent where one ends and another begins.  This sounds stupid until you realize that for the 33rd time you've just edited the wrong thing.  When you have lots and lots of code files and you do things fast, this really does happen (over 1,000+ php files on my main website alone).  I move my sql statements onto one or more lines intentionally like this:

  $query = "

SELECT * FROM '$maintable'


I've never seen anyone else do this so it deserves some explanation.  Here's a little secret – my SQL isn't always perfect.  This approach lets me easily copy and paste SQL statements into PHPMyAdmin or another query tool for testing.  Since I do most of my coding under Linux these days and I use VI in character mode, I don't have perfect mouse selection and this technique pretty much guarantees that I get the right code selected with just one swipe of the mouse.  Given that most of my scripts tend to revolve around 1 main data table per PHP module I also define the name of that table as a variable at the beginning of the php file so I can move SQL statements from module to module with less changes (it's quite disconcerting when your changelog starts displaying contacts instead of changes!).

Template Driven Layout or "display"

Given the blog world's focus on content templates and the seperation of content from presentation, no one is probably surprise to learn that I'm a fan of this too.  Thankfully PHP offers lots and lots of ways to do this and I didn't have to write my own routines (I'm not a big fan of low level blocks; give me application specific code, thank you very much!).  Here are some of the approaches to this in PHP that I am aware of:

And there's more.  Whenever code is involved, the PHP community does seem to be able to take on lots of different approaches to the problem.

Right now, today, I'm not using Smarty.  I'm still using FastTemplate for all my projects.  Sure I know that it's obsolete and that I should move to Smarty.  But I have stuff working already.  I know how to use it.  And, like most developers, I'm wicked conservative when it comes to things that break my own stuff.  And, while Smarty is better without question, when you already know something, you tend to stick with it.  At some point we'll FuzzyOffice to Smarty en masse and enjoy the pain of it as a _shared_ exercise!  Anyway, back to template driven layout …

The basic idea of template based layout is simple – pull the HTML (mostly) out of the PHP code and create a "template" containing variables where the PHP code can insert values for the variables.  All a template is to FastTemplate is an HTML file with some markup conventions. 


Network I/O


Da Code Boss!  Da Code!

Here's a link to all the code discussed here:

What I did was take advantage of PHP's .PHPS syntax coloring feature.  This feature, taught to me by my buddy Apokalyptik, lets a *nix symbolic link (think Windows Shortcut or Macintosh Alias) to a source file be displayed in a color coded fashion.  The symbolic links are created with a command like this:

ln -s index.php index.phps

Now if you go to the url for that .phps file, you get this (try it):

comment []

Copyright 2002 © The FuzzyStuff