I have the welcome page but now what jedd

Category:Approaches::I have the welcome page - but now what

Approach (brief):

These are the things I tend to do / adopt / setup: o my .htaccess file is pretty stable now, and it's the first thing I setup o nomenclature standard o MY_Controller, with a few functions I would probably use in every project o MY_Model .. ditto o assets directory - for images, javascript and other 'static' stuff o phpdoc - for automating the documentation of my code o git - my version control system of choice o trac - for ticketing and wiki o various little approaches I follow from here ...

Approach (in detail):

my .htaccess file - to remove the annoying index.php from the URL

This is documented in the CI user guide already, but there's a fair bit of choice on the format for your .htaccess file. This is what mine looks like:

# jedd 2009-02 - obviates requirement for index.php in URLs
RewriteEngine on
RewriteCond $1 !^(index\.php|files|assets|robots\.txt)
RewriteRule ^(.*)$ ./index.php/$1 [L]

Observations ... I have directories in my root called files and assets that I don't want CI messing with, and you can easily add more in there as you need. I call ./index.php - but you could hard code the PATH in there if you prefer (I like it this way as I never have to change it for a new project).

And don't forget to change the the config/config.php file:

$config['index_page'] = "";

Nomenclature standards

I really dislike using a _model suffix on my Model names, so instead I shop around for synonyms (where applicable) or just rely on the fact that my models (which typically front several database tables) don't really need to clash with my controllers (which present a user perspective of a particular resource).

Model and Controller names, as well as table and column names in my DB, are consistently singular.

Controllers tend to be nouns, and their methods tend to be verbs. This aligns with the 'controller is a resource manager', as well as the 'method is a way of doing something' approaches. People who don't follow this approach, as a very general rule, at least if the forums are indicative - are usually much more confused about their controller design.

MY_Controller

MY_Model

assets directory - for images, javascript and other 'static' stuff

phpdoc - documentation generator

There's two popular PHP documentation utilities out there, and I happen to have discovered phpdoc first.

It is a script, that uses the PHP command line interpreter, that runs through your code and produces a set of web pages that describe all your functions and classes and stuff.

All that's required on your end is to put in those comment blocks that you've probably seen used everywhere already - they look like this. If you don't put these blocks in, you'll still get some useful pages out of phpdoc, but they won't be as useful.

/**
 * Forum
 *
 * Handles public message forums
 *
 * @link        Message (Model) - which handles all message-related tables
 * @package     pdb
 * @version     v0.9
 * @author      jedd
 * @link        http://my.web.site/trac/pdb
 **/

With CodeIgniter, or I guess any framework, the trick is to only include the bits of the framework that you need to in order to have your code doco make sense without overloading it with the framework's methods and classes. In my case I want CI's Controller and Model, but none of the other CI libraries included in my documentation set.

My phpdoc shell script (for Debian GNU/Linux, but would work on any distro I guess, and probably OSX - but no idea how you'd go about doing this on MS-Windows) lives in my project root directory, and the output is to a peer directory. In this case my project is in /var/www/devel/pdb and my phpdoc dumps its output into /var/www/devel/pdbdoc.

I run this manually, but it's an ideal candidate for a cron job - the thing takes about 4 seconds on a 2Ghz box with 2GB.

#!/bin/bash
phpdoc -d /var/www/devel/pdb/app \
        -f /var/www/devel/pdb/system/libraries/Model.php \
        -f /var/www/devel/pdb/system/libraries/Controller.php \
        --defaultpackagename "pdb" \
        --parseprivate \
        -t /var/www/devel/pdbdoc/ \
        -ti DOC-pdb

#  stuff I might put back in later ...
#  --output "HTML:frames:phpedit" \

git - version control

There are lots of resources out on the Intergoogle about setting up and using git - and I recommend this one for starters: Git for the lazy person.

git is insanely easy to set up - pretty much 'git init' - and it's about a half hour to get your head around the basic functions. Perhaps less if you're already familiar with Subversion or something similar.

git lets you easily revert to (and come back from just as easily) a 'given point in time copy' - assuming you get into the habit of committing your changes regularly - and that alone is worth the price of admission.

Yes, you'll use a smidgen more space, but disk is cheap, and you are likely doing regular backups of your development environment anyway. This just makes those backups even more useful (note - it doesn't replace the need for backups - oh no).

trac - for project ticketing and documenting

This is yet another tool that people assume works best for multi-people projects, but I find it's handy to have one dedicated to each project, even little ones. It's inexpensive (it uses sqlite) and easy to set up, and gives me a place to make notes to myself about wishlist items and bugs that I've found but haven't got around to fixing yet. It's also a great source-code browser, with plugins for git and svn and a few other CVS suites.

Various little things ...