[Phpug] PHP webapp structure - my way

[Barry O'Donovan]

Folks,

It seems everyone has different models for putting PHP web applications 
together. I just thought I share mine - which is heavily influenced by a 
number of popular open source web apps - to see if there are any comments or 
suggestions. 

What does everyone else do?


The file structure usually breaks down like this:

web_app/
web_app/bin/
web_app/config/
web_app/classes/
web_app/classes/class.database.php
web_app/classes/class.person.php
web_app/components/
web_app/components/component.subscribe.php
web_app/lib/
web_app/log/
web_app/public/
web_app/public/index.php
web_app/public/css/
web_app/public/js/
web_app/public/images/
web_app/public/downloads/
web_app/templates/
web_app/templates/en/
web_app/templates/fr/
web_app/templates_c/
web_app/thirdparty/
web_app/thirdparty/app1
web_app/thirdparty/app2

The basic idea is that the web functionality will be built up in public/ with 
the only directly accessible PHP file being index.php. Everything comes 
through this file and this file is responsible for session management, 
authentication, database initialisation, etc. It can certainly include helper 
files (eg a database initialisation file) but, as stated, the only point of 
contact to the website is index.php.

This ensures that all functionality is centralised to a single point; 
authentication and access control will not be forgotten or broken through 
programmer error in other places; application design is intuitive and clear.

Functionality is broken down to core components/processors and 
actions/sections are accessed and linked via GET parameters. For example:

    
https://www.showreelplayer.com/index.php?component=subscribe&task=getDetails

Classes are particularly used to encapsulate database tables and relevant 
functionality. e.g. a user table would encapsulate a registered user, their 
username, password, contact and other relevant details and provide methods to 
change their password, update their e-mail, create a new user, etc. Each 
table encapsulation class is of course subclassed from a database class 
providing the database functionality.

The thirdparty/ directory is used to separate the projects code from other, 
third party code. It can be PHP included/required by the project code using 
PHP functions (include, require), it can be directories that are symbolically 
linked from the public directory or aliased by Apache for example. It's more 
a mechanism of separation than anything else. Reliance on third party 
applications that provide web front ends is avoided where possible as it 
would move away from the index.php method mentioned above. Third party 
applications are usually just libraries providing functionality for the 
components.

The template/ directory then of course is the Smarty templates. It can also be 
provided to external web designed via an SVN checkout of just the templates 
directory keeping the actual functionality secure. 

bin/ is for PHP and other scripts that may form part of the application such 
as those to be executed by a cron job. config/ can hold .inc s containing 
database access details, etc. lib/ can hold .inc/php s containing libraries 
of functions that don't fit in a class. log/ is pretty obvious.

Generally speaking and outside of items such as the Smarty library, PHP PEAR 
classes, etc, the application should be self-contained in this structure. 
Paths should be relative or customisable by simple variables located in a 
file under config/.


I'd like to say I always use this but sometimes deadlines push me into 
shortcuts!

Any thoughts?

Thanks,
Barry