Do not forget to add the following autoload directive to your hooks/doctrine.php and the doctrine.php cli:

spl_autoload_register(array('Doctrine', 'modelsAutoload'));

However, there are some issues to solve when installing the platform from source. Mainly you'll be missing several packages. The following commands worked at my own Debian machine. If you find out that's something is missing that was apparently already installed on my machine, don't hesitate to leave a comment.

The following commands are all executed as root.
First we need to download the sources, I'm using the x86 sources, but feel free to use the x64 version:

cd /tmp
wget http://www.haskell.org/ghc/dist/6.10.4/ghc-6.10.4-i386-unknown-linux-n.tar.bz2
wget http://hackage.haskell.org/platform/2009.2.0.2/haskell-platform-2009.2.0.2.tar.gz

Now we need to extract these sources:

tar xvf ghc-6.10.4-i386-unknown-linux-n.tar.bz2
tar xvzf haskell-platform-2009.2.0.2.tar.gz

Before we do any other stuff, let's ensure that we have all the packages and libraries we need before continuing.

apt-get install build-essential libghc6-opengl-dev libghc6-glut-dev libeditline-dev libedit2 libedit-dev

Also make sure that you apply this patch to the platform, the bug has been around for some time now but hasn't been fixed apparently, it can be found at bug #84:

patch -p0 haskell-platform-2009.2.0.2/scripts/install.sh
Index: haskell-platform-2009.2.0.2/scripts/install.sh
===================================================================
--- haskell-platform-2009.2.0.2.orig/scripts/install.sh
+++ haskell-platform-2009.2.0.2/scripts/install.sh
@@ -34,13 +34,23 @@ install_pkg () {
   fi
 }
+# Is this exact version of the package already installed?
+is_pkg_installed () {
+  PKG_VER=$1
+  grep " ${PKG_VER} " installed.packages > /dev/null 2>&1
+}
+
 # Actually do something!
 cd packages
 for pkg in `cat platform.packages`; do
-  cd "${pkg}" || die "The directory for the component ${PKG} is missing"
-  echo "Installing ${pkg}..."
-  install_pkg ${pkg}
-  cd ..
+  if is_pkg_installed "${pkg}"; then
+    echo "Platform package ${pkg} is already installed. Skipping..."
+  else
+    cd "${pkg}" || die "The directory for the component ${PKG} is missing"
+    echo "Installing ${pkg}..."
+    install_pkg ${pkg}
+    cd ..
+  fi
 done
 echo

Now go to the ghc dir and build it.

cd ghc-6.10.4
./configure
make install

And if all of this goes well you can now go to the haskell-platform dir and install it:

cd ../haskell-platform-2009.2.0.2/
./configure
make
make install

And done! :)

Welcome back. In this post we will look at creating type algebra's and folds for more complicated data types. In essence, this exercise will not be any more difficult than the previous ones, provided that you stick with the steps. Up in this part, are the non-mutually recursive datatypes and mutually recursive datatypes.

First up, data structures that are recursive into other data structures. The folds for these data structures are no more complex than their `simpler' forms. In fact, you could treat them the same, but for clarity we will treat them as distinct. If you want to know more about the previous part, it might help your search if you look for the keyword catamorphism.

Non-mutually recursive datastructures

Look at the following data structure. It's data constructors refer both back to the data structure itself and to another data structure. The other data structure has no reference back to this structure. This kind of data structures are quite common.

data MaybeTree a = Node (Maybe a) (MaybeTree a) (MaybeTree a)
                   | Leaf (Maybe a)
-- This one is already defined in the prelude
data Maybe a = Just a | Nothing

Recall that in our previous folds and algebras we choose to replace our self-recursive types with a free variable r. In this case we also have a reference to another data structure, namely Maybe a. We will denote this by using another free variable, lets say m.

type MaybeTreeAlgebra a m r = (  ( m -> r -> r -> r -- Node
                                 , m -> r           -- Leaf
                                 )
                              ,  ( a -> m           -- Just
                                 , m                -- Nothing
                                 )
                              )

Notice that we've split up the the functions for each data type in separate tuples. This is to make the algebra somewhat more readable. It has one disadvantage though which we'll see later on.

We obtained this algebra by methodically looking at the types of the constructor functions and replacing any recursive types by their free variable counterparts, r for MaybeTree a and m for Maybe a.

Now we are going to construct the fold function. We will be doing this in exactly the same way as we did with all previous folds.

1. Determine which datatypes are used (previously there was only one); This step is very simple if you already have the algebra.
2. for each of these datatypes exhaustively define a fold function;
3. look at the result.

Following these steps again gives us the fold on our datatype. Please convince yourself that this is the case by defining foldMaybeTree yourself.

If we do it exactly as described above it will provide us with the following fold. Notice that we gave meaningful names to every replacement function stating the datatype they are intended for. Except for the top level function which we called f. This is because writing out the whole name for that function everywhere would be to much of a hassle and if you use f for this way it will be quite clear in time.

foldMaybeTree' :: MaybeTreeAlgebra a m r -> MaybeTree a -> r
foldMaybeTree' ((node, leaf), (just, nothing)) = f
  where f (Node x l r) = node (maybe x) (f l) (f r)
        f (Leaf x)     = leaf (maybe x)
        maybe (Just x)  = just x
        maybe (Nothing) = nothing

Notice that we are using a datatype here that is already defined in the prelude. It would be wise to check whether someone didn't already provide a fold function for our little datatype Maybe a. Because that's we essentially did, we inlined the fold for Maybe a inside our fold for MaybeTree a. Obviously this isn't a problem if you are sure that your datatype will stay `contained in' in your datatype.

So we see that it is prudent to check for already existing folds if we use already existing datatypes. And it turns out that there already is a fold for Maybe a, namely maybe.

maybe :: b -> (a -> b) -> Maybe a -> b
maybe n _ Nothing  = n
maybe _ f (Just x) = f x

So lets refine our little procedure to determine the fold of a datatype:

1. Determine which datatypes are used (previously there was only one); This step is very simple if you already have the algebra.
2. for each of these datatypes exhaustively define a fold function or check whether such a fold function already exists;
3. look at the result.

If we now use this knowledge our fold function can be written as follows:

foldMaybeTree :: MaybeTreeAlgebra a m r -> MaybeTree a -> r
foldMaybeTree ((node, leaf), (just, nothing)) = f
  where f (Node x l r) = node (fmaybe x) (f l) (f r)
        f (Leaf x)     = leaf (fmaybe x)
        fmaybe = maybe nothing just

We've seen how to use algebra's but we haven't seen a step by step procedure for creating one. So let's add that to our procedure for creating our own folds. In our order to create the algebras as we've seen them here, with tupled functions you can follow this procedure:

For each data constructor in your datatype: create a function that takes the same parameters as the constructor function and replace every occurrence of a reference to one of your datatypes with a unique type variable (two occurrences to the same type should get the same variable). These functions should be grouped in tuples by their datatype. Do not forget to name all the type variables in the left-hand side of the type definition.

This could potentially fail, in case you get the aforementioned error. Be sure to remove these files before proceeding. To check whether there are any, go to the directory and retrieve it's listing.

cd /some/path/to/your/yml/files
ls -lha

If you see any files starting with a dot and ending in .yml be sure to check them for any valuable content and throw them away.

Thanks to rajat pandit for hinting to this solution.

During our functional programming course at Utrecht University I noticed students having anxiety of datatypes and even more for folds. Not because they couldn't grasp the workings of a single example but more a lack of a view on the complete picture and lack of experience with the Haskell datatype way.

So, what are datatypes? Datatypes are a way of notating the abstract structure of your data. There are several datastructures known to man, such as lists and trees.

Lists

Lists in Haskell are used in several ways. Today we will look at how to calculate the sum of a list. Intuitively you calculate the sum of a list by adding its elements together. Starting with the first element and then continuing on to the rest. This is how we literally translate that thought into Haskell code:

sum :: [Int] -> Int
sum []     = 0
sum (x:xs) = x + sum xs
-- sum [1..4] = 10

Would we be calculating the product of the list, we'd do the same except we multiply instead of adding.

product :: [Int] -> Int
product []     = 1
product (x:xs) = x * product xs
-- product [1..4] = 24

Looking at these two examples we can see that we have two similarities. We always have recursion on the tail of the list and we do something with the head of the list and the result of the recursion. In the first example we add them together, and in product we multiply them. Another property of most functions over lists is that there is a base case for the empty list. We call this the identity of our function, sometimes also referred to as unit. The identity of addition is 0 and the identity of multiplication is 1.

Now we look at one of the folds over lists defined in the prelude, foldr. Make sure you know what each parameter stands for. Note: There are some downsides to this function, mostly that it will not work for large lists, you'll see more on this later.

foldr :: (a -> b -> b) -> b -> [a] -> b
foldr f z []     = z
foldr f z (x:xs) = f x (foldr f z xs)
-- The line above can also be written as:
-- foldr f z (x:xs) = x `f` (foldr f z xs)

Now, take a moment to let this function soak in and try to think of how you would define sum and product in terms of this foldr. Crucial at this point is to notice that we do not see any type hardcoded in the type of foldr It may be helpful to look at this fold, which is the identity function for lists:

idList :: [a] -> [a]
idList list = foldr (:) [] list
-- Recall: [1,2,3,4,5] == 1 : 2 : 3 : 4 : 5 : []

If we look at our sum function, the operator between each recursive call is (+) and our base case is 0. So that's what we are going to use for our sum in terms of foldr.

sumList :: [Int] -> Int
sumList list = foldr (+) 0 list
-- sumList [1..4] = 10

Thus far we only have lists of Int for our examples. However, for sake of usability we will now move on to lists of numeric elements. Because (+) is defined for all numbers. (If you wish to read more on this subject please look up classes and instances.) Notice how the type of sumList changes while it's definition remains unaltered.

sumList :: Num a => [a] -> a
sumList list = foldr (+) 0 list

Now that we have seen how we can determine the function and identity for our fold from our recursive function to a definition in terms of foldr. And most importantly, the foldr takes care of the recursive nature of the list for us and the only thing it asks us in return for that is an operator and an identity for your operation. So the fold can now be used to define several operations on lists.

I told you about a problem of foldr. Depending on the size of your list the above sumList may not work. Try the following on your machine:

$ ghci
Prelude> let sumList = foldr (+) 0
Prelude> sumList [1..1000000]
*** Exception: stack overflow

Now try:

$ ghci
Prelude> let sumList = Data.List.foldl' (+) 0
Prelude> sumList [1..1000000]
500000500000

For a complete overview and analysis on foldr and foldl please read A tutorial on the universality and expressiveness of fold, by Graham Hutton.

Trees

First, let's take a look at how data structures in Haskell can be defined. In short we have the data keyword, followed by zero or more type variables, a = and then a number of data constructors separated by a |.

Now that you have familiarized yourself with lists we can proceed to a slightly more complicated datastructure. The Tree. In this example we will use a simple binary tree. A binary tree can be denoted as follows:

data BinTree a = Node a (BinTree a) (BinTree a) | Leaf deriving (Show, Eq)

In this case BinTree is the type constructor and Node and Leaf the data data constructors.

Remember that the goal of folds is to seperate the implementation of the recursion from the actual operation we want to execute on the datatype. So we have one function, the fold, that takes care of the recursion and several other functions that use this fold to specify certain semantics on the datatype. We are going to calculate the sum of all elements in this tree.

The above binary tree has elements in the nodes and nothing in the leaves. You can notice the recursive occurrence of `BinTree a' in the node. We see two constructors in this datatype, Node and Leaf. The Node constructor expects some value of type a and two subtrees of type BinTree a, and the Leaf constructor has no parameters. In Haskell:

Node :: a -> BinTree a -> BinTree a -> BinTree a
Leaf :: BinTree a

Notice that our list also has two constructors, namely the (:) constructor that adds an element and the constructor for the empty list, []. Analogously we have the Node and Leaf constructors. If we were allowed to use the (:) and [] constructor in our own Haskell code, the datatype for a list would look like this:

data List a = (:) a (List a) | []

Also, it is customary to keep the arguments for the functions in the same order as the constructors are defined in the datatype, and to name the identifiers containing the functions the same as the constructor function but in lowercase. Applying this we get:

foldBinTree :: (a -> BinTree a -> BinTree a -> BinTree a) -> (BinTree a) -> BinTree a -> ??
foldBinTree node leaf = f
  where f (Node x left right) = node x (f left) (f right)
        f (Leaf)              = leaf

I left out the result type of this fold, try to find it yourself before continuing.

By following our code we can see that every case, the case for Node and the one for Leaf, result in a BinTree a. Consequently the complete result of the function is a BinTree a

Now recall that we previously used a fold to calculate the sum of a list. With that fold we were not restricted to a list. Which is also clearly visible by looking at the type of foldr it contains only type variables. As we want to calculate sum of the elements in this tree, which is something of type a and not of type BinTree a we have to revise the type of our fold. Notice the recurrence of the datatype in it's declaration, BinTree a. We will replace all of these occurences in the types of our functions with a free type variable, say r:

foldBinTree :: (a -> r -> r -> r) -> (r) -> BinTree a -> r
foldBinTree node leaf = f
  where f (Node x left right) = node x (f left) (f right)
        f (Leaf)              = leaf

Keep in mind that I used 'eta reduction' in the above code. This means that the last parameter (in this case the tree) isn't explicitly specified as it would appear at the very end of the parameter list and ath the very end of the definition. (More on eta reduction.) So, now let's do something with this fold. Suppose we have the following tree:

bintree = Node 1
            (Node 2
              (Node 3 Leaf Leaf)
              (Node 3 Leaf Leaf)
            )
            (Node 2
              (Node 3 Leaf Leaf)
              (Node 3 Leaf Leaf)
            )

A visual representation:

            1
          /  \
         2    2
        / \  / \
       3   3 3  3

Now we can define several traversals over this tree. Let's calculate the sum of all values in the tree.

sumBinTree :: Num a => BinTree a -> a
sumBinTree = foldBinTree (\val res_left res_right -> val + res_left + res_right)
                         0

Algebras

The type of our foldBinTree is now more compact. However, there will be datatypes that contain a larger sum of constructors that also may have more or less parameters than in our case. Defining the type of the fold on those datatypes as we have done before will inevitably lead to very clumsy type signatures. The idea is that we split up the section that denotes our functions into a separate type, namely the algebra.

So now we define an algebra for our datastructure. To do this we again look at each dataconstructor and determine it's type. The fold function takes care of the recursion, so applying this thought consequently gives us the following types and fold.

Keep in mind that we have to change the type of our fold, but not the definition of the fold itself!

type BinTreeAlgebra a r = (a -> r -> r -> r, -- Node
                           r -- Leaf
                          )
foldBinTree :: BinTreeAlgebra a r -> BinTree a -> r

Now we can again define a sum on all Num a trees. Notice that we went from to seperate parameters for the functions to one tuple with two elements.

sumBinTree :: Num a => BinTree a -> a
sumBinTree = foldBinTree (\val res_left res_right -> val + res_left + res_right,
                          0)

$ ghci bintree.hs
*Main> bintree
Node 1 (Node 2 (Node 3 Leaf Leaf) (Node 3 Leaf Leaf)) (Node 2 (Node 3 Leaf Leaf) (Node 3 Leaf Leaf))
*Main> sumBinTree bintree
19

That's it for now. If you did not understand everything by the end of this article, don't panic. It will sink in eventually. Let this rest a day or two, and then read this article again and you'll understand folds better. :)

First, we want to store our applications and CodeIgniter releases in separate folders. So for example store your CodeIgniter system folder in /var/codeigniter/. This could be done by doing a svn export (or checkout) with the following command-line statement:

$ svn export http://dev.ellislab.com/svn/CodeIgniter/tags/v1.7.1/system/ /var/codeigniter/release-1.7.1

Or you can download the 1.7.1 release from the CodeIgniter website and copy the contents of the system folder to /var/codeigniter/release-1.7.1.

Now for each application you want to build you can do a export/checkout to our applications directory. As we are going to store our applications outside the document root you could pick /var/applications/ as root directory for your CI applications. Now if you want to make a blog you just have to execute this command:

$ svn export http://dev.ellislab.com/svn/CodeIgniter/tags/v1.7.1/system/application/ /var/applications/blog

or

$ cp /var/codeigniter/release-1.7.1/application /var/applications/blog

I prefer the SVN export as this will ensure that you always have a fresh copy. Otherwise, should you find yourself without an internet connection you can use the latter.

Now just as in the previous post, create the directory in the document root (whether you want to access it through a subfolder or directly through a sub-domain/domain is entirely up to you and is outside the scope of this post.)

$ mkdir /var/www/blog

Now get the index.php file from svn or from the zip file you might have downloaded earlier:

svn export http://dev.ellislab.com/svn/CodeIgniter/tags/v1.7.1/index.php /var/applications/blog/

The only thing left is to alter the index.php so the $system_folder and the $application_folder point in the right direction:

 //...
$system_folder = '/var/codeigniter/release-1.7.1';
//...
$application_folder = '/var/applications/blog';

Now you can add your web stuff like CSS, JS  to your /var/www/blog. Of course this follows the same principle as creating the non-www and www directories mentioned in the previous post.

Now for each application you want to add, retake the above steps and replace 'blog' with something relevant. Good steaming!

When I first started working with the MVC method it was with my own framework. After noticing that maintaining my own framework would be very time-comsuming I embarked on the search for a free, fast and widely supported PHP web framework. The one I found that time was 'CodeIgniter'.

After working on different projects I noticed that most websites present the same data to the visitor in several different formats. Think of RSS/Atom for blog posts for use in an RSS reader together with the (x)html versions.

While essentially providing the same data to the visitor the programmer of the website has to put sizable amount of work to add little extra functionality in the form of an RSS feed. Repeating a lod of code for input validation, data retrieval from the database and creating extra routes into the application. As you can imagine this could grow into a tedious job.

I'll be describing techniques known and in use today, but reinvented each time again as a (new) developer starts working on an web application. Here we'll be giving them name and be describing them.

Theory

What are layouts? What are partials? The answers to these questions will be discussed in the following sections.

Layouts

What is a layout? We will be using the following definition of the word layout: "A layout is the representation of data in a specific format". So the layout of a page can be either, xhtml, RSS, PDF, PPT or any other data format.

Suppose you would find yourself in the situation where you need to write a blog. You could start with building the models that describe users, posts, comments and maybe even backtracks. Then you start writing the controllers and views and let someone else do the design for you. :)

So, the designer has made some nice designs and you are converting those to (x)html, CSS and images for use in your views. In the same time you write your controllers, one for every aspect of your blog. Consider the controller that shows a list of your most recent posts.

Blogs are essentially meant for publishing information, the messages the poster posts, to the world. People want to see a nice readable web page when they look at your blog. But it is hard to keep track of all the blogs one visits for new posts. That's why people invented the syndicates. And look now, here you are, having two URLs providing the same information, the latest posts, and the only difference is that the information is that they present the data in another format. So why should the URLs be different? - Other than the extension that denotes in which format the page should be presented? - Right, they shouldn't. Nor should you have to write any administrative code. The only code you should have to write is the code responsible for presenting the given data in a specific layout.

With just a small amount of initial trouble, which we'll see in the next chapter, it will save you a lot of time and administrative rut. Sounds good, doesn't it?

Partials

Another aspect of this article is 'partials'. Programming today is all about re-using code and rapid development and low-maintenance. OOP gives you the ability to re-use your previously written code you worked so hard on in a sensible matter. It also can help in reducing the draught of maintenance. The MVC paradigm is extending this and helps by further aiding rapid development.

In the aspect of re-using code, partials are very important. Where OOP , Models and Controllers can save you time by re-using program code, partials can help you save time by offering a new way to re-use your html (or any other layout) code. Thus not only decreasing the maintenance needed for your application but simultaneously increasing consistency throughout your application without causing you any headaches.

Where does the name 'partial' come from? The origins of this name are quite simple. A 'partial' is a small re-usable snippet of View code and is a View itself.

Partials can be used for many things. For example, the header on all your blog pages could be the same, apart from variables as titles and needed stylesheets and javascript includes. As we have learned during the age of the static webpages, maintaining this would be an hell of a pain. So let's not do that anymore and let's use partials instead. Keep the code in one place and just use the partial if you need the header. Do no retype or copy any code.

Of course, headers and footers are not the only things that we can store in partials. The menu, the login form, the code for a blog post and the lot can be placed in partials. Actually almost anything that will be used more than once should be placed in a partial.

An implementation in CodeIgniter

This part shows one way to implement layouts and partials in CodeIgniter. We assume you have at least version 1.6.3 of CodeIgniter and that you have a fair idea of what we are going to do. Proceeding is completely at your own expense and I am not accountable for any issues that may rise do to these adjustments

Adjustments

The Controller class

The first thing we have to do is extending the main controller class provided by CodeIgniter. This enables us to do whatever we want without changing anything in the CodeIgniter code base. Place this function in the extending controller:

<?php
  /**
   * This function remaps the url and retrieves the desired extension from it. It then calls the appropiate controller method.
   *
   * @param string $aMethod
   */
  function _remap($aMethod) {
    $lParams = $this->uri->segment_array();
    array_shift($lParams);array_shift($lParams);
 
    $lMethod = $aMethod;
    $lLayout = 'xhtml';
    if (strpos($lMethod, '.') !== False)
      list($lMethod, $lLayout) = explode('.', $lMethod);
    $this->load->setLayout($lLayout);
 
    $lMethod = (empty($lMethod) ? 'index' : $lMethod);
 
    if (method_exists($this, $lMethod) && !method_exists(__CLASS__, $lMethod)) {
      call_user_func_array(array($this, $lMethod), $lParams);
    }
    else {
      show_404($lMethod);
    }
  }
?>
 

The loader

Now put these functions inside class extending the CI Loader class:

<?php
protected $layout;

public function partial($aPartial, $aData=array(), $aLayout=null) {
  $lLayout = (is_null($aLayout) ? $this->layout : $aLayout);
 
  $lastItem = '';
  $parts    = array();
  if (strpos($aPartial, '/') !== false) {
    $parts = explode('/', $aPartial);
 
    $lastItem = array_pop($parts);
  }
  else {
    $lastItem = $aPartial;
  }
 
  if ($lastItem{0} !== '_') {
    $lastItem = '_'.$lastItem;
  }
  array_push($parts, $lastItem);
 
  $this->view(implode('/', $parts), $aData, $aLayout);
}
 
public function setLayout($aLayout) {
  if (is_dir(APPPATH.'/views/'.$aLayout)) {
    $this->layout = $aLayout;
  }
}
 
/**
 * @param string $aView
 */
public function view($aView=null, $aData=array(), $aLayout=null) {
  if (is_null($aView))
  $aView = $this->controllerName.'/'.$this->controllerFunction;
 
  $lLayout = (is_null($aLayout) ? $this->layout : $aLayout);
  parent::view($lLayout.DIRECTORY_SEPARATOR.$aView, $aData);
}
?>
 

Usage

Views

Now that we have extended the functionality of CodeIgniter with our own we can start to use layouts and partials. Consider the following url:

http://someurl/blog/category/5

It will give you a nice and cheesy overview formatted in xhtml. So let's take a look at the view file.

<?php $this->partial('header', $data); ?>
<div id="content">
  <?php
  foreach ($posts as $post)
    $this->partial('blog/shortsummary', array('post' => $post));
  ?>
</div>
 
<?php $this->partial('footer', $data); ?>
 

And the code for the short summary looks like this:

 
<div class="blog post short">
<h2><?= $post->title; ?></h2>
 
  <span class="description"><?= $post->description; ?></span>
</div>
 

Now consider this url:

http://someurl/blog/category.rss/5

This url would give you the overview of the posts in category 5. Just as with the url above. But this time the information will be formatted in RSS. Notice that the only thing we had to do was to change the url. Create these two files:

APPPATH/views/rss/blog/summary.php

<channel>
  <items>
  <?php
    foreach ($posts as $post)
      $this->partial('blog/shortsummary', array('post' => $post));
  ?>
  </items>
</channel>
 

APPPATH/views/rss/blog/_shortsummary.php

<?php
assert(!is_null($post));
?>
<item>
  <title><?=$post->title;?></title>
  <description><?=$post->description;?></description>
</item>
 

Wow. Now we only had to write a few lines (15) for adding RSS feeds to our site. This is really all there is to it. Now go out there and have fun.

Seperating both `system' and `application' has obvious advantages for maintainance and for reusibility. Using a seperate `www' directory enables you to publish all your application specific JS/CSS and other public files.

The first thing we need to do is to create an checkout of the latest CodeIgniter release (currently 1.7.1)
$ svn checkout http://dev.ellislab.com/svn/CodeIgniter/tags/v1.7.1/ somepathoutsidedocumentroot

now move the application folder outside the system folder:

$ cd somepathoutsidedocumentroot
$ mv system/application ./application

Now move the system and application folder to some folder outside of your public document root. Let's call this directory `non-www'. The documentroot directory will be called `www'.

In the root of your checkout you will find an index.php. Copy/move this file to www. Open it and look for the following lines:

$system_folder = "system";
$application_folder = "application";

Change them to the following:

$system_folder = "../non-www/system";
$application  = "../non-www/application";

Now you are up and running. Probably you want something like nice url's. For this you can use the following .htaccess

RewriteEngine on
RewriteRule ([^/]*)\/\?([^/?]*)$ $1/$2 [R]

RewriteCond $1 !^(index\.php|test\.php|export\.php|robots\.txt|css|img|js|favicon\.ico|doc|data|user_guide|js)
RewriteRule ^(.*)$ ./index.php/$1 [L]

Now, go and create some new shiny sites.

To counter this (and other annoying pestering little details mongering), Object Relational Mappers were invented. Doctrine is a PHP implementation of the RoR ORM. And now it's quite easy to merge CodeIgniter and Doctrine into one package.

Just follow the readme and continue your adventure.