Skip to content

I have the welcome page but now what jedd

World Wide Web Server edited this page Jul 4, 2012 · 18 revisions

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

[color=green]Very much a work in progress - 20090824T1300GMT[/color]

[h2]Overview:[/h2]

Disclaimer - I'm using Quanta on KDE on Debian GNU/Linux, but that doesn't affect much of the following, as it's primarily CI code/structure changes, and software that's available across pretty much every platform.

[h2]Approach (brief):[/h2]

These are the things I tend to setup [b]o[/b] my .htaccess file is pretty stable now, and it's the first thing I setup [b]o[/b] MY_Controller, with a few functions I would probably use in every project [b]o[/b] MY_Model .. ditto [b]o[/b] phpdoc - for automating the documentation of my code [b]o[/b] git - my version control system of choice [b]o[/b] various little approaches I follow from here ...

[h2]Approach (in detail):[/h2]

[h3]my .htaccess file - to remove the annoying index.php from the URL[/h3]

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: [code]

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] [/code]

Observations ... I have directories in my root called [b]files[/b] and [b]assets[/b] 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 [b]config/config.php[/b] file: [code] $config['index_page'] = ""; [/code]

[h3]MY_Controller[/h3]

[h3]MY_Model[/h3]

[h3]phpdoc - documentation generator[/h3] There's two popular PHP documentation utilities out there, and I happen to have discovered [url="http://www.phpdoc.org/"]phpdoc[/url] 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 [i]as[/i] useful.

[code] /**

  • 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 **/ [/code]

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 [i]your[/i] 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 [b]/var/www/devel/pdb[/b] and my phpdoc dumps its output into [b]/var/www/devel/pdbdoc[/b].

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.

[code] #!/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" \

[/code]

[h3]git - version control[/h3] There are lots of resources out on the Intergoogle about setting up and using git - and I highly recommend this one for starters: [url="http://www.spheredev.org/wiki/Git_for_the_lazy"]Git for the lazy person[/url]. git is insanely easy to set up - pretty much 'git init' - and it's very easy to get your head around the basic functions within a half hour. It lets you revert to 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 bit 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).

[h3]Various little things ... [/h3]

Clone this wiki locally