PHP and Stuff

CodeIgniter and Doctrine from scratch. Day 11 – Record Hooks

Burak — Mon, 08 Feb 2010 21:24:33 +0000

In this tutorial we will be looking into Doctrine Record Hooks. This will allow us to trigger certain actions in our Models.

We are going to use this feature to simplify a few things in the existing code, and even gain some performance benefits.

"CodeIgniter and Doctrine from Scratch" Series:

Record Hooks

In the Day 8 article we talked about CodeIgniter Hooks. This time we are going to look at Record Hooks with Doctrine.

Hooks are used to execute certain code when a certain event is triggered. Record Hooks are used when something happens with a Doctrine Record. For example we can use the postInsert hook to do some task every time a new record is inserted.

Here is a list of all available Record Hooks:

preSave
postSave
preUpdate
postUpdate
preInsert
postInsert
preDelete
postDelete
preValidate
postValidate

To use a one of these hooks, simply add a method with that name into the Doctrine_Record model:

class Post extends Doctrine_Record {

	public function setTableDefinition() {
		// ...
	}

	public function setUp() {
		// ...
	}

	public function postInsert() {
		// a new record was inserted
		// you can put some code here
	}

}

Let’s look at what we are going to be doing today to utilize this feature.

Forum Display Page Improvements

In the Day 9 article we built a page for displaying all Threads under a Forum.

Let’s look at the code we used for getting the list of threads:

// from the Forum model

// ...
	public function getThreadsArray($offset, $limit) {

		$threads = Doctrine_Query::create()
			->select('t.title')
			->addSelect('p.id, (COUNT(p.id) - 1) as num_replies')
			->addSelect('MIN(p.id) as first_post_id')
			->addSelect('MAX(p.created_at) as last_post_date')
			->from('Thread t, t.Posts p')
			->where('t.forum_id = ?', $this->id)
			->groupBy('t.id')
			->orderBy('last_post_date DESC')
			->limit($limit)
			->offset($offset)
			->setHydrationMode(Doctrine::HYDRATE_ARRAY)
			->execute();

		foreach ($threads as &$thread) {

			$post = Doctrine_Query::create()
				->select('p.created_at, u.username')
				->from('Post p, p.User u')
				->where('p.id = ?', $thread['Posts'][0]['first_post_id'])
				->setHydrationMode(Doctrine::HYDRATE_ARRAY)
				->fetchOne();

			$thread['num_replies'] = $thread['Posts'][0]['num_replies'];
			$thread['created_at'] = $post['created_at'];
			$thread['username'] = $post['User']['username'];
			$thread['user_id'] = $post['User']['id'];
			unset($thread['Posts']);

		}

		return $threads;

	}
// ...

There are two main DQL queries. The first one for fetching the Threads, and the second one, inside of a loop, for fetching further details about each Thread, such as number of replies, the username etc…

There is quite a bit going on in there. With the changes we will make today, we will be able to reduce that into a single DQL call.

Adding a “First_Post” Relationship

We first had to get the id of the first post, and then get information on that post in another DQL query. If we had a direct relationship with a “First_Post” record, it would simplify things.

Edit: system/application/models/thread.php

hasColumn('title', 'string', 255);
		$this->hasColumn('forum_id', 'integer', 4);
		$this->hasColumn('first_post_id', 'integer', 4);
	}

	public function setUp() {
		$this->hasOne('Forum', array(
			'local' => 'forum_id',
			'foreign' => 'id'
		));
		$this->hasMany('Post as Posts', array(
			'local' => 'id',
			'foreign' => 'thread_id'
		));

		$this->hasOne('Post as First_Post', array(
			'local' => 'first_post_id',
			'foreign' => 'id'
		));
	}

}

The highlighted lines have been added. Now each Thread will have a relationship with a Post record, which will be the first Post in that Thread.

Setting up the Hook

When a new Post is added, if it is the first Post in that Thread, it needs to be assigned to the First_Post relationship. This will be done with the following “postInsert” Record Hook.

Edit: system/application/models/post.php

exists()) {
			$this['Thread']['First_Post'] = $this;
			$this['Thread']->save();
		}

	}

}

Note that “postInsert” means, “after” insert. It has nothing to do with the class name “Post”.

This function gets invoked right after a new Post record was created.

First we check if a First_Post relationship exists, with the exist() function. If not, we assign “$this”, which is the current Post record, to this relationship with the corresponding Thread record.

Rebuild the Database

Drop all tables.

You may use this query:

SET FOREIGN_KEY_CHECKS = 0;
DROP TABLE category, forum, post, thread, user;

Now we need to rebuild it all.

Go to: http://localhost/ci_doctrine/doctrine_tools/create_tables and click the button.
Go to: http://localhost/ci_doctrine/doctrine_tools/load_fixtures and click the button.

Now all the tables are rebuilt and the fixture data is reloaded.

Take a look at your thread table:

You can see the new column. And thanks to the Record Hook, the values have been assigned already.

Simplify Things

Now we can go ahead and simplify the “getThreadsArray” method under the Forum Model.

Edit: system/application/models/forum.php

select('t.title')
			->addSelect('p.id, (COUNT(p.id) - 1) as num_replies')
			->addSelect('MAX(p.created_at) as last_post_date')
			->addSelect('fp.created_at, u.username')
			->from('Thread t, t.Posts p, t.First_Post fp, fp.User u')
			->where('t.forum_id = ?', $this->id)
			->groupBy('t.id')
			->orderBy('last_post_date DESC')
			->limit($limit)
			->offset($offset)
			->setHydrationMode(Doctrine::HYDRATE_ARRAY)
			->execute();

		foreach ($threads as &$thread) {

			$thread['num_replies'] = $thread['Posts'][0]['num_replies'];
			$thread['created_at'] = $thread['First_Post']['created_at'];
			$thread['username'] = $thread['First_Post']['User']['username'];
			$thread['user_id'] = $thread['First_Post']['User']['id'];

			unset($thread['Posts']);

		}

		return $threads;

	}

}

Line 13: Now we have 2 more relationships in the from() call. First_Post and the User for the First_Post.
Line 12: We select the created_at and username fields from these new relationships.
Line 25,26,27: These lines have been changed to use the new fields.
Also the DQL query inside the loop is now gone. This should have a positive impact on performance.

Note that the loop now is only being used to simplify the $threads array structure, so it’s actually optional.

Testing the Results

We haven’t really changed anything on the actual pages. So everything should look the same as before.

Stay Tuned

There are many things you can do with Hooks and Listeners in Doctrine. Make sure to read the documentation.

I hope you enjoyed this tutorial. See you next time!

"CodeIgniter and Doctrine from Scratch" Series:

CodeIgniter and Doctrine from scratch. Day 10 – Pagination

Burak — Wed, 20 Jan 2010 07:42:19 +0000

Today we will be working on Pagination.

"CodeIgniter and Doctrine from Scratch" Series:

Upgrading Doctrine

Before we get started, let’s upgrade Doctrine.

When I wrote the first article in this series, Doctrine 1.1 was the current stable version at the time. Since then, 1.2 has come out. Luckily it is backwards compatible with 1.1.

So, if you are like me and have been using Doctrine 1.1, just follow these steps to upgrade to 1.2.

Delete folder: system/application/plugins/doctrine/lib
Download Doctrine 1.2 and extract.
Copy the lib folder to system/application/plugins/doctrine

One Small Fix

At some point I did find an issue that wasn’t backwards compatible. I modified the previous articles to fix that issue but some of you may not have done this if you read those articles before I changed them.

Edit: system/application/controllers/home.php

select('c.title, f.title, f.description')
			->addSelect('t.id, COUNT(t.id) as num_threads')
			->from('Category c, c.Forums f')
			->leftJoin('f.Threads t')
			->groupBy('f.id')
			->execute();

		$vars['title'] = 'Home';
		$vars['content_view'] = 'forum_list';
		$vars['container_css'] = 'forums';

		$this->load->view('template', $vars);
	}

}

It’s just the highlighted line. The ‘t.id’ needed to be added to the addselect() or COUNT(t.id) did not work properly.

That is all. If your website is loading without errors, everything should be fine.

What is Pagination?

Displaying data in multiple pages is Pagination.

There are two main parts to this. First we need to generate links to the pages.

Pagination Links

Here is an example from CodeIgniter Forums:

That looks simple, but we also need to consider what happens when we start going to other pages:

Now there is a “Prev” link which we didn’t have before. And we see links to 5 page numbers instead of 3.

Things change even more if we go deeper:

Now there is also a “<< First" link, because the link for Page 1 is no longer visible.

One more:

The “Last >>” link disappeared because we already have a link to Page 89, which is the last page.

Another example from Digg.com:

As you can see they are doing it quite differently. It’s all a matter of preference.

Let’s look at the way they do the links.

CodeIgniter Forums:


http://codeigniter.com/forums/viewforum/59/

http://codeigniter.com/forums/viewforum/59/P25/

http://codeigniter.com/forums/viewforum/59/P50/

Those were the links for the first, second and third page. The first page gets no parameter as it works with default values. But the second and third pages have these “P25″ and “P50″ parameters at the end. Strangely enough these are not page numbers. They actually represent the offset value for the records instead, as they display 25 records per page.

Digg.com:


http://digg.com/all/upcoming

http://digg.com/all/upcoming/page2

http://digg.com/all/upcoming/page3

Again, we see a difference between the two websites. Digg.com prefers to use actual page numbers instead of offset numbers.

Paginating Data

This is the second part to this Pagination subject. Our code needs to be responsible for displaying the correct set of data on each page.

In terms of raw SQL, here is how you can get a set of records for a given page:

SELECT * FROM table LIMIT 50, 25

The LIMIT clause does the job. In this particular query, we fetch 25 records, starting after the first 50 records. So, 50 is the offset and 25 is the limit, i.e. the number of records.

With Doctrine we will be using DQL rather than raw SQL queries.

Let’s say we have a URL like they do on CodeIgniter forums:


http://codeigniter.com/forums/viewforum/59/P125/

That would translate into having the offset 125. And the limit would always be 25, because internally we decide to display 25 threads per page.

If we have a Digg style pagination URL:


http://digg.com/all/upcoming/page7

We need to multiply 7 with the “per page” count. So it could be 175 (7*25) offset and 25 limit, if the per page limit is set to 25. But we are not going to be using this method.

CodeIgniter Pagination Library

CodeIgniter comes with a nice simple Pagination Library, which we will be using. First, I will explain it briefly.

Let’s put some code in a test Controller.

Edit: system/application/controllers/test.php

class Test extends Controller {

	function paginate() {

		$this->load->library('pagination');

		$config['base_url'] = base_url() . "test/paginate";
		$config['total_rows'] = '200';
		$config['per_page'] = '10';

		$this->pagination->initialize($config);

		echo $this->pagination->create_links();

	}

}

The code is very simple. We just provide the base url, number of total records, and the number of records per page.

The results look like this:

And the links look like this:


http://localhost/ci_doctrine/test/paginate/

http://localhost/ci_doctrine/test/paginate/10

http://localhost/ci_doctrine/test/paginate/20

http://localhost/ci_doctrine/test/paginate/30

http://localhost/ci_doctrine/test/paginate/40

So this library puts the offset number, rather than the page number at the end of the URL’s.

Also, with this library you can customize the HTML structure of the links. You can see more information about that in the documentation.

Adding More Data

First we are going to add some more data to our database so we have something to paginate.

All we have to do is add more stuff to the fixture file we have been using before:

Edit: system/fixtures/data.yml

User:
  Admin:
    username: Administrator
    password: testing
    email: programming@gmail.com
  Test:
    username: TestUser
    password: mypass
    email: test@test.com
  Foo:
    username: Foobar
    password: mypass
    email: test2@test2.com

Forum:
  Forum_1:
    title: Introduce Yourself!
    description: >
      Use this forum to introduce yourself to the CodeIgniter community,
      or to announce your new CI powered site.
  Forum_2:
    title: The Lounge
    description: >
      CodeIgniter's social forum where you can discuss anything not related
      to development. No topics off limits... but be civil.
  Forum_3:
    title: CodeIgniter Discussion
    description: This forum is for general topics related to CodeIgniter.
  Forum_4:
    title: Code and Application Development
    description: >
      Use the forum to discuss anything related to
      programming and code development.
  Forum_5:
    title: Ignited Code
    description: >
      Use this forum to post plugins, libraries, or other code contributions,
      or to ask questions about any of them.

Category:
  Lounge:
    title: The CodeIgniter Lounge
    Forums: [Forum_1, Forum_2]
  Dev:
    title: CodeIgniter Development Forums
    Forums: [Forum_3, Forum_4, Forum_5]

Thread:
  Thread_1:
    title: Hi there!
    Forum: Forum_1
  Thread_2:
    title: Greetings to all
    Forum: Forum_1
  Thread_3:
    title: Sed vitae ligula erat
    Forum: Forum_3
  Thread_4:
    title: Vivamus laoreet quam vitae mauris tempus
    Forum: Forum_3
  Thread_5:
    title: Maecenas vel dolor odio
    Forum: Forum_3
  Thread_6:
    title: In nec justo at orci fermentum
    Forum: Forum_3
  Thread_7:
    title: Nullam volutpat laoreet orci
    Forum: Forum_3
  Thread_8:
    title: Sed sodales augue vel elit
    Forum: Forum_3
  Thread_9:
    title: Integer posuere luctus metus
    Forum: Forum_3
  Thread_10:
    title: Maecenas ut mauris eget odio pharetra
    Forum: Forum_3
  Thread_11:
    title: Pellentesque lacinia nibh vel lacus
    Forum: Forum_3
  Thread_12:
    title: Nunc facilisis nibh a nulla laoreet in ultricies
    Forum: Forum_3
  Thread_13:
    title: Maecenas pretium nisi eget nunc rutrum quis
    Forum: Forum_3
  Thread_14:
    title: Etiam at ligula leo
    Forum: Forum_3
  Thread_15:
    title: Vivamus tempus semper libero
    Forum: Forum_3
  Thread_16:
    title: Phasellus venenatis consectetur quam
    Forum: Forum_3
  Thread_17:
    title: Nam sagittis elementum turpis
    Forum: Forum_3
  Thread_18:
    title: Sed at odio id ante rutrum sodales
    Forum: Forum_3
  Thread_19:
    title: Praesent eget lorem nec odio
    Forum: Forum_3
  Thread_20:
    title: Donec at enim sit amet quam
    Forum: Forum_3
  Thread_21:
    title: Ut sit amet ante nec leo volutpat
    Forum: Forum_3
  Thread_22:
    title: Pellentesque accumsan orci nec
    Forum: Forum_3
  Thread_23:
    title: Curabitur convallis sapien in dolor feugiat
    Forum: Forum_3
  Thread_24:
    title: Aenean sodales massa in dui ultrices
    Forum: Forum_3

Post:
  Post_1:
    Thread: Thread_1
    User: Test
    created_at: '2009-11-20 01:20:30'
    updated_at: '2009-11-20 01:20:30'
    content: >
      Hello everyone! My name is Test, and I go to school at
      Test Institute of Technology in the US.
      I just found CodeIgniter some time last week and have been
      reading through the documentation trying to get myself acquainted.

      Hopefully the forums will be a great help! I already have some questions.
      Thanks!
  Post_2:
    Thread: Thread_1
    User: Admin
    created_at: '2009-11-20 02:15:33'
    updated_at: '2009-11-20 02:15:33'
    content: Welcome Test! Nice to meet you.
  Post_3:
    Thread: Thread_2
    User: Foo
    created_at: '2009-11-19 12:14:50'
    updated_at: '2009-11-19 12:14:50'
    content: I am new here. Just wanted to say hi.
  Post_4:
    Thread: Thread_3
    User: Foo
    created_at: '2009-12-01 12:14:50'
    updated_at: '2009-12-01 12:14:50'
    content: Vivamus ultricies hendrerit justo, sit amet semper nulla scelerisque pulvinar.
  Post_5:
    Thread: Thread_4
    User: Foo
    created_at: '2009-12-02 12:14:50'
    updated_at: '2009-12-02 12:14:50'
    content: Sed luctus enim ut magna pellentesque mollis.
  Post_6:
    Thread: Thread_5
    User: Foo
    created_at: '2009-12-03 12:14:50'
    updated_at: '2009-12-03 12:14:50'
    content: Nam id nisi dolor, vel interdum turpis.
  Post_7:
    Thread: Thread_6
    User: Foo
    created_at: '2009-12-04 12:14:50'
    updated_at: '2009-12-04 12:14:50'
    content: Donec volutpat accumsan lorem, at euismod metus lobortis viverra.
  Post_8:
    Thread: Thread_7
    User: Foo
    created_at: '2009-12-05 12:14:50'
    updated_at: '2009-12-05 12:14:50'
    content: Nulla vestibulum erat ac nisi convallis rutrum.
  Post_9:
    Thread: Thread_8
    User: Foo
    created_at: '2009-12-06 12:14:50'
    updated_at: '2009-12-06 12:14:50'
    content: Nulla pharetra tortor id ante sollicitudin sodales.
  Post_10:
    Thread: Thread_9
    User: Foo
    created_at: '2009-12-07 12:14:50'
    updated_at: '2009-12-07 12:14:50'
    content: Cras id metus a elit mattis blandit et aliquet diam.
  Post_11:
    Thread: Thread_10
    User: Foo
    created_at: '2009-12-08 12:14:50'
    updated_at: '2009-12-08 12:14:50'
    content: Nunc non felis vitae dolor posuere aliquam non et augue.
  Post_12:
    Thread: Thread_11
    User: Foo
    created_at: '2009-12-09 12:14:50'
    updated_at: '2009-12-09 12:14:50'
    content: Nam et velit ac tellus interdum adipiscing.
  Post_13:
    Thread: Thread_12
    User: Foo
    created_at: '2009-12-10 12:14:50'
    updated_at: '2009-12-10 12:14:50'
    content: Donec viverra leo mauris, ac convallis turpis.
  Post_14:
    Thread: Thread_13
    User: Foo
    created_at: '2009-12-11 12:14:50'
    updated_at: '2009-12-11 12:14:50'
    content: Integer sagittis nisl ut nisi euismod in dignissim massa sagittis.
  Post_15:
    Thread: Thread_14
    User: Foo
    created_at: '2009-12-12 12:14:50'
    updated_at: '2009-12-12 12:14:50'
    content: Integer vel lectus mollis quam sollicitudin porta.
  Post_16:
    Thread: Thread_15
    User: Foo
    created_at: '2009-12-13 12:14:50'
    updated_at: '2009-12-13 12:14:50'
    content: Etiam tempor luctus sem, at consequat enim posuere in.
  Post_17:
    Thread: Thread_16
    User: Foo
    created_at: '2009-12-14 12:14:50'
    updated_at: '2009-12-14 12:14:50'
    content: Proin placerat lectus dolor, quis viverra ante.
  Post_18:
    Thread: Thread_17
    User: Foo
    created_at: '2009-12-15 12:14:50'
    updated_at: '2009-12-15 12:14:50'
    content: Maecenas ullamcorper commodo leo, lobortis molestie turpis cursus sit amet.
  Post_19:
    Thread: Thread_18
    User: Foo
    created_at: '2009-12-16 12:14:50'
    updated_at: '2009-12-16 12:14:50'
    content: Integer tincidunt facilisis dolor, vitae pellentesque turpis rutrum sed.
  Post_20:
    Thread: Thread_19
    User: Foo
    created_at: '2009-12-17 12:14:50'
    updated_at: '2009-12-17 12:14:50'
    content: Donec eget lacus a nibh volutpat venenatis quis a felis.
  Post_21:
    Thread: Thread_20
    User: Foo
    created_at: '2009-12-18 12:14:50'
    updated_at: '2009-12-18 12:14:50'
    content: Nam fringilla tellus quis augue elementum eleifend.
  Post_22:
    Thread: Thread_21
    User: Foo
    created_at: '2009-12-19 12:14:50'
    updated_at: '2009-12-19 12:14:50'
    content: Nullam sollicitudin nulla at orci accumsan eget ultrices felis vehicula.
  Post_23:
    Thread: Thread_22
    User: Foo
    created_at: '2009-12-20 12:14:50'
    updated_at: '2009-12-20 12:14:50'
    content: Nullam sit amet purus nec mauris convallis tincidunt sodales eget nunc.
  Post_24:
    Thread: Thread_23
    User: Foo
    created_at: '2009-12-21 12:14:50'
    updated_at: '2009-12-21 12:14:50'
    content: Praesent in eros non elit ultricies tincidunt a nec tellus.
  Post_25:
    Thread: Thread_24
    User: Foo
    created_at: '2009-12-22 12:14:50'
    updated_at: '2009-12-22 12:14:50'
    content: Aenean ac nisl a sapien pulvinar gravida et quis metus.

Now load this fixture:

Go to: http://localhost/ci_doctrine/doctrine_tools/load_fixtures
Hit the button.
Go home: http://localhost/ci_doctrine/

You should see this:

Click the “CodeIgniter Discussion” link

You should see:

Sorting By Last Post Date

As it is, the Threads are not being sorted by a specific column, because we did not add that to the DQL query last time. They need to be sorted by the “created_at” date of the last Post in that Thread, in descending order. Let’s fix that now.

Edit: system/application/models/forum.php

class Forum extends Doctrine_Record {

// ...

	public function getThreadsArray() {

		$threads = Doctrine_Query::create()
			->select('t.title')
			->addSelect('p.id, (COUNT(p.id) - 1) as num_replies')
			->addSelect('MIN(p.id) as first_post_id')
			->addSelect('MAX(p.created_at) as last_post_date')
			->from('Thread t, t.Posts p')
			->where('t.forum_id = ?', $this->id)
			->groupBy('t.id')
			->orderBy('last_post_date DESC')
			->setHydrationMode(Doctrine::HYDRATE_ARRAY)
			->execute();

		foreach ($threads as &$thread) {

			$post = Doctrine_Query::create()
				->select('p.created_at, u.username')
				->from('Post p, p.User u')
				->where('p.id = ?', $thread['Posts'][0]['first_post_id'])
				->setHydrationMode(Doctrine::HYDRATE_ARRAY)
				->fetchOne();

			$thread['num_replies'] = $thread['Posts'][0]['num_replies'];
			$thread['created_at'] = $post['created_at'];
			$thread['username'] = $post['User']['username'];
			$thread['user_id'] = $post['User']['id'];
			unset($thread['Posts']);

		}

		return $threads;

	}

}

The highlighted lines have been added. They should be self-explanatory.

We should also update the View so it shows that date.

Edit: system/application/views/forum.php






	
		
		( replies)
	

	
		Author: ,
		Last Post:

Pagination Links

Now, to do pagination, we need 3 pieces of information:

Total number of records. In our case, number of Threads.
Number of records per page. We can pick any number. I will set it to 4 for now so we can have several pages.
Current page number or record offset. Since CodeIgniter Pagination library works with the offset number, rather than page number, that’s what we will use.

We need to edit the View, the Model and the Controller.

The View

Let’s set the output of the pagination links in the View.

Edit: system/application/views/forum.php






	
		
		( replies)
	

	
		Author: ,
		Last Post: 
	





	
		Pages:

At line 20, we check to see if the $pagination variable is set, which will contain the pagination links, because sometimes there won’t be enough records to paginate.

The Model

Now let’s modify the Forum Model.

Edit: system/application/models/forum.php

hasColumn('title', 'string', 255);
		$this->hasColumn('description', 'string', 255);
		$this->hasColumn('category_id', 'integer', 4);
	}

	public function setUp() {
		$this->hasOne('Category', array(
			'local' => 'category_id',
			'foreign' => 'id'
		));
		$this->hasMany('Thread as Threads', array(
			'local' => 'id',
			'foreign' => 'forum_id'
		));
	}

	public function numThreads() {

		$result = Doctrine_Query::create()
			->select('COUNT(*) as num_threads')
			->from('Thread')
			->where('forum_id = ?', $this->id)
			->setHydrationMode(Doctrine::HYDRATE_ARRAY)
			->fetchOne();

		return $result['num_threads'];

	}

	public function getThreadsArray($offset, $limit) {

		$threads = Doctrine_Query::create()
			->select('t.title')
			->addSelect('p.id, (COUNT(p.id) - 1) as num_replies')
			->addSelect('MIN(p.id) as first_post_id')
			->addSelect('MAX(p.created_at) as last_post_date')
			->from('Thread t, t.Posts p')
			->where('t.forum_id = ?', $this->id)
			->groupBy('t.id')
			->orderBy('last_post_date DESC')
			->limit($limit)
			->offset($offset)
			->setHydrationMode(Doctrine::HYDRATE_ARRAY)
			->execute();

		foreach ($threads as &$thread) {

			$post = Doctrine_Query::create()
				->select('p.created_at, u.username')
				->from('Post p, p.User u')
				->where('p.id = ?', $thread['Posts'][0]['first_post_id'])
				->setHydrationMode(Doctrine::HYDRATE_ARRAY)
				->fetchOne();

			$thread['num_replies'] = $thread['Posts'][0]['num_replies'];
			$thread['created_at'] = $post['created_at'];
			$thread['username'] = $post['User']['username'];
			$thread['user_id'] = $post['User']['id'];
			unset($thread['Posts']);

		}

		return $threads;

	}

}

Line 21: Added new method named “numThreads”, since we are going to need the total number of Threads.

Note: I know that it would have been simpler to just use this code: “$this->Threads->count()”. However, unfortunately Doctrine creates a very inefficient query when we do that, that’s why I used a DQL query instead.

Line 34: Just added 2 parameters to the existing function, since we are only interested in the Thread records for a given page.

Lines 45-46: Here we use the given $offset and $limit parameters to limit the DQL query results.

The Controller

Finally we update the Forums Controller.

Edit: system/application/controllers/forums.php

find($id);

		$vars['title'] = $forum['title'];
		$vars['threads'] = $forum->getThreadsArray(
			$offset,
			$per_page
		);
		$vars['content_view'] = 'forum';
		$vars['container_css'] = 'forum';

		$num_threads = $forum->numThreads();

		// do we have enough to paginate
		if ($num_threads > $per_page) {
			// PAGINATION
			$this->load->library('pagination');
			$config['base_url'] = base_url() . "forums/display/$id";
			$config['total_rows'] = $num_threads;
			$config['per_page'] = $per_page;
			$config['uri_segment'] = 4;
			$this->pagination->initialize($config);

			$vars['pagination'] = $this->pagination->create_links();
		}

		$this->load->view('template', $vars);

	}

}

Updated lines are highlighted.

Line 4: Now there is a second parameter named $offset, because the paginated URL’s will contain the offset after the Forum id.

Line 6: Here we pick a number of Threads per page. Normally it could be 10, 20 or 25, but for this test we are picking a smaller number.

Lines 12-13: We send the 2 parameters that the getThreadsArray method is expecting.

Line 21: We only do pagination if there are more records than the $per_page number.

Line 27: We have to set the ‘uri_segment’ setting for the Pagination library. This is the uri segment that will carry the offset number. If not set, it defaults to uri segment 3. For example the URL will look like this:


http://localhost/ci_doctrine/forums/display/53/8

“forums” is uri segment 1, “display” is uri segment 2, “53″ is uri segment 3 and the Forum id, “8″ is the URI segment 4 and the $offset variable.

The Result

Go to: http://localhost/ci_doctrine/
Click the forum name: “CodeIgniter Discussion”

You should see:

Continue clicking on the pagination links:

Seems to be working

Stay Tuned

Thank you for reading, and sorry about the delay. We still have more work to do. See you next time!

"CodeIgniter and Doctrine from Scratch" Series:

CodeIgniter and Doctrine from scratch. Day 9 – Templates & Data Hydrators

Burak — Mon, 14 Dec 2009 00:04:45 +0000

In this article we are going to create Templates (with CodeIgniter) to keep our Views organized, and avoid repeating the same HTML code. Also we are going to learn about Doctrine Data Hydrators to see alternative ways to structure the data returned from the database.

"CodeIgniter and Doctrine from Scratch" Series:

Templates

What and Why?

The term Template might be a little ambiguous right now. Maybe you are already thinking of Views as Templates. Which is mostly true. However, there is a problem with using separate Views for every single page in our application. There will be headers, footers and other content that will be repeated everywhere. That’s why there is a need for actual Templates for our Views.

For example, we will be creating a new View for the Forum pages. It will look mostly the same as the home page, using the same css stylesheet, same header, same user control panel, etc… There will be other Views later that will be the same way. If we ever make a change to any of these common parts, we don’t want to go through every single View. There should be Views that have the common html output that we can quickly edit. Using Templates will enable us to do just that, and maybe more.

Creating a Template

Let’s create our first Template, which is actually going to be a View itself. The idea is to keep all the common elements in one file, and take out the variable stuff.

For example, take a look at this:

The content section is definitely going to change from page to page. Also, I would like to take out the user controls section, so it can have its own View. We’re going to replace these with some code instead.

Create: system/application/views/template.php




	
	<?php echo $title; ?> | CI+Doctrine Message Board
	





	
		load->view('user_controls'); ?>
	

	CI+Doctrine Message Board

	load->view($content_view); ?>

I have copied the contents of the Home View we created before, and replaced a few things.

Line 14: The code for the user_controls div will now be found in a View named user_controls.php.
Line 19: $content_view is the name of the View that will be loaded to fill up the content area. For example, we will use a View named forum_list for the home page. The controller will have to pass this variable.
Line 5: Now the page title can be passed as a $title variable.
Line 11: We can apply a different css class for the container div on every page.

As you can see, a View can load other Views. That’s a big help in creating Templates. Now, all Controllers can just load this Template View, and they can pass the name for a content View that will be loaded in the middle of the page.

Now let’s create the user_controls View.

Create: system/application/views/user_controls.php


	Hello, username; ?> 

	

	 |

Basically it’s the same code as before, but now it is in its own View file.

Now let’s create the forum_list View.

Create: system/application/views/forum_list.php




	title; ?>

	Forums as $forum): ?>
	

		
			id, $forum->title) ?>
			(Threads[0]->num_threads; ?> threads)
		

		
			description; ?>

This code is also taken from the middle section of the old Home View. (I only made a small change to the link at line 10.)

Now we can get rid of the Home View file.

Delete: system/application/views/home.php

Updating the Home Controller

This new Template needs to know what content to load, what the title of the page is, etc… So we need to update the Home Controller.

Edit: system/application/controllers/home.php

select('c.title, f.title, f.description')
			->addSelect('t.id, COUNT(t.id) as num_threads')
			->from('Category c, c.Forums f')
			->leftJoin('f.Threads t')
			->groupBy('f.id')
			->execute();

		$vars['title'] = 'Home';
		$vars['content_view'] = 'forum_list';
		$vars['container_css'] = 'forums';

		$this->load->view('template', $vars);
	}	

}

The changes are only the highlighted lines. We are now passing the page title, name of the content View, and a CSS class name for styling purposes. Then we load the View named ‘template’ instead of ‘home’ (since we deleted that one).

See the Results

Go to: http://localhost/ci_doctrine/

The page should look exactly the same as before:

Later in this article we are going to use this Template to build the Forum page, that lists Threads in a Forum.

Data Hydrators (Doctrine)

Our Doctrine Models extend the Doctrine_Record class. We have been using instances of this class for representing and persisting the database records. Also, we have been using instances of the Doctrine_Collection class when dealing with multiple records (e.g. fetching multiple rows with DQL).

With Data Hydrators, we can work with the data in other structure formats. For example, with DQL we can have it return the results of a SELECT query as an Array instead of Doctrine_Collection.

HYDRATE_SCALAR

This returns an array similar to what you would get from doing raw SQL queries.

$category = Doctrine_Query::create()
	->select('c.*, f.*')
	->from('Category c, c.Forums f')
	->where('c.id = ?', 1)
	->setHydrationMode(Doctrine::HYDRATE_SCALAR)
	->execute();

print_r($category);
/* output:
Array
(
    [0] => Array
        (
            [c_id] => 1
            [c_title] => The CodeIgniter Lounge
            [f_id] => 1
            [f_title] => Introduce Yourself!
            [f_description] => Use this forum to introduce yourself to the CodeIgniter community, or to announce your new CI powered site.

            [f_category_id] => 1
        )

    [1] => Array
        (
            [c_id] => 1
            [c_title] => The CodeIgniter Lounge
            [f_id] => 2
            [f_title] => The Lounge
            [f_description] => CodeIgniter's social forum where you can discuss anything not related to development. No topics off limits... but be civil.

            [f_category_id] => 1
        )

)
*/

We fetched the Category with id 1, and it’s associated Forums. There were 2 Forums under that Category, so the result contains 2 rows of data.

If I run the same raw query from phpMyAdmin, it looks like this:

Note that the Category title is repeated in both rows, because of the nature of JOIN queries. That is also the case in the Array that was returned by DQL.

HYDRATE_ARRAY

This also returns an Array. But this time, it will have a nice multi-tier structure based on the Model relationships.

$category = Doctrine_Query::create()
	->select('c.*, f.*')
	->from('Category c, c.Forums f')
	->where('c.id = ?', 1)
	->setHydrationMode(Doctrine::HYDRATE_ARRAY)
	->execute();

print_r($category);
/* output:
Array
(
    [0] => Array
        (
            [id] => 1
            [title] => The CodeIgniter Lounge
            [Forums] => Array
                (
                    [0] => Array
                        (
                            [id] => 1
                            [title] => Introduce Yourself!
                            [description] => Use this forum to introduce yourself to the CodeIgniter community, or to announce your new CI powered site.

                            [category_id] => 1
                        )

                    [1] => Array
                        (
                            [id] => 2
                            [title] => The Lounge
                            [description] => CodeIgniter's social forum where you can discuss anything not related to development. No topics off limits... but be civil.

                            [category_id] => 1
                        )

                )

        )

)
*/

Now we have a multidimensional Array. As you can see, this time the Category info is not repeated. And Forums is a sub-array under the Category. Also the keys of the array retain their original names, like ‘title’, instead of ‘c_title’.

Other Hydrators

By default Doctrine is using HYDRATE_RECORD, that causes objects to be returned. And there are a few other Hydrators you can read about here: http://www.doctrine-project.org/documentation/manual/1_2/en/data-hydrators

Why?

Hydrators can have certain performance benefits. Creating an array is faster than creating an object that has lots of overhead. And arrays take less memory too.

Also there are things you can do with arrays that you cannot do with a Doctrine object. If you prefer to handle the data as an array, Hydration is the way to go.

We are going to be using HYDRATE_ARRAY to fetch a list of Threads in the following sections, to demonstrate the usage.

CSS Changes

Before we move on, I want to make some CSS changes, so the new pages we build will be styled.

Edit: css/style.css

body {
	font-family: "Trebuchet MS",Arial;
	font-size: 14px;
	background-color: #212426;
	color: #B9AA81;
}
a			{color: #FFF;}
a:hover		{color: #B9AA81;}
input, textarea, select {
	font-family:inherit; font-size:inherit;	font-weight:inherit;
}
.container	{width: 720px; margin: auto;}
/* FORUMS -----------------------------------------*/
.forums.container h2 {
	font-size: 16px;
	color: #000;
	padding: 5px 10px 5px 10px;
	margin: 0px;
	background-color: #BBB;
	-moz-border-radius-topleft: 6px;
	-moz-border-radius-topright: 6px;
	-webkit-border-top-left-radius: 6px;
	-webkit-border-top-right-radius: 6px;
}
.forums.container h3			{font-size: 15px; margin: 0px;}
.forums.container .category 	{margin-bottom: 40px;}
.forums.container .forum 		{border-bottom: 1px solid #666;	padding: 10px;}
.forums.container .forum .description	{font-size: 14px;}
/* FORUM -----------------------------------------*/
.forum.container h2 {
	font-size: 16px;
	color: #000;
	padding: 5px 10px 5px 10px;
	margin: 0px;
	background-color: #BBB;
	-moz-border-radius-topleft: 6px;
	-moz-border-radius-topright: 6px;
	-webkit-border-top-left-radius: 6px;
	-webkit-border-top-right-radius: 6px;
}
.forum.container h3			{font-size: 15px; margin: 0px 0px 5px 0px;}
.forum.container .thread	{border-bottom: 1px solid #666;	padding: 10px;}
/* SIGNUP FORM ------------------------------------*/
#signup_form	{margin: auto; width: 360px; font-size: 16px;}
#signup_form .heading {
	text-align: center;	font-size: 22px; font-weight: bold;	color: #B9AA81;
}
#signup_form form {
	background-color: #B9AA81;
	padding: 10px;
	-moz-border-radius: 8px;
	-webkit-border-radius: 8px;
}
#signup_form form label {font-weight: bold;	color: #11151E;}
#signup_form form input[type=text],input[type=password] {
	width: 316px;
	font-weight: bold;
	padding: 8px;
	border: 1px solid #FFF;
	-moz-border-radius: 4px;
	-webkit-border-radius: 4px;
}
#signup_form form input[type=submit] {
	display: block;
	margin: auto;
	width: 200px;
	font-size: 18px;
	background-color: #FFF;
	border: 1px solid #BBB;
}
#signup_form form input[type=submit]:hover {border-color: #000;}
#signup_form .error {font-size: 13px; color: #690C07; font-style: italic; }
/* USER CONTROL BOX -------------------------------*/
.user_controls {float: right; text-align: right;}

Forum Pages

Now, let’s use what we have, to build the Forum Pages. These pages will list all the Threads, in a given Forum.

Currently, on the Home page we have links like this:

We created these links, because we expect to have a Controller named ‘Forums’ that has a function named ‘Display’.

There is also an ID number at the end of the URL. That is passed to the Controller function as a parameter.

This Controller is supposed to load a page that lists all the Threads in that particular Forum.

Forums Controller

The skeleton structure first:

Create: system/application/controllers/forums.php


It looks like any other Controller. But this time we are expecting a parameter being passed to the display() method. The string that comes after /forums/display/ in the URL automatically gets passed as the first parameter to that method.
For example: 

http://localhost/ci_doctrine/forums/display/1

Will call display(1) in the Forums Class. We are going to use that parameter as the Forum ID. Then we need to display the Forum page.
The Controller needs to obtain the following pieces of data, and pass them on to the View:

The title of the Forum.
Each Thread under the Forum.
For each Thread, we need Thread title, create date, author name and number of replies.

Please note that the create date of the Thread is not part of the Thread Model (or table), because of the way we designed the Models. The first Post inside of the Thread carries a create date already, so we did not want to duplicate that data again. Same thing goes for the author (or user_id) of the Thread.
Now let’s add some code to make this happen:
find($id);

		$vars['title'] = $forum['title'];
		$vars['threads'] = $forum->getThreadsArray();
		$vars['content_view'] = 'forum';
		$vars['container_css'] = 'forum';

		$this->load->view('template', $vars);

	}

}

First we get an instance of the Forum object with the id $id. Then we create the array of variables that will be passed to the template View.
At line 9 you can see that I am attempting to call a method named getThreadsArray(). This does not exist yet, so let’s build it.
The idea is to create a method that can return all associated Threads in an array structure. But we also want each Thread to have information such as: number of replies, date (of first post), author of (first post).

Edit: system/application/models/forum.php

select('t.title')
			->addSelect('p.id, (COUNT(p.id) - 1) as num_replies')
			->addSelect('MIN(p.id) as first_post_id')
			->from('Thread t, t.Posts p')
			->where('t.forum_id = ?', $this->id)
			->groupBy('t.id')
			->setHydrationMode(Doctrine::HYDRATE_ARRAY)
			->execute();

		foreach ($threads as &$thread) {

			$post = Doctrine_Query::create()
				->select('p.created_at, u.username')
				->from('Post p, p.User u')
				->where('p.id = ?', $thread['Posts'][0]['first_post_id'])
				->setHydrationMode(Doctrine::HYDRATE_ARRAY)
				->fetchOne();

			$thread['num_replies'] = $thread['Posts'][0]['num_replies'];
			$thread['created_at'] = $post['created_at'];
			$thread['username'] = $post['User']['username'];
			$thread['user_id'] = $post['User']['id'];
			unset($thread['Posts']);

		}

		return $threads;

	}

In the first DQL query:
Look at the from() call first. We are joining 2 Models (Thread, Post) because we need information from both. 
Now look at the select() and addSelect() calls to see what we are getting:

- We select the title for every Thread.

- Then we select the number of Posts under each Thread by using COUNT(p.id), and subtract 1 to get number of replies.

- Finally we are also getting the ID for the first Post in that Thread using MIN(p.id). That will be used later in the second DQL query.
where(‘t.forum_id = ?’, $this->id) indicates which Forum id we are looking up.
groupBy(‘t.id’) groups the results by the Thread id, so the Post count works properly.
Then, we loop through the Threads to get some more data into each Thread:
In the first query we fetched the ID of the first post on each Thread and stored it as first_post_id. So this DQL query now gets data for that Post and also the username of its author by joining to the related User Model.
The rest of the code, I just arranged all the values in $thread so it has a nice structure when returned.
Just to give you a better picture, if you were to print_r $threads , it would look this this:
Array
(
    [0] => Array
        (
            [id] => 1
            [title] => Hi there!
            [num_replies] => 1
            [first_post_id] => 1
            [created_at] => 2009-12-13 13:00:09
            [username] => TestUser
            [user_id] => 2
        )

    [1] => Array
        (
            [id] => 2
            [title] => Greetings to all
            [num_replies] => 0
            [first_post_id] => 3
            [created_at] => 2009-12-13 13:00:09
            [username] => Foobar
            [user_id] => 3
        )

)

I did unset($thread['Posts']) in the code just to keep the resulting array cleaner.
Note that we used HYDRATE_ARRAY, like we talked about earlier. This allowed us to do 2 things that we couldn’t have done with Doctrine_Collection objects:

- When we foreach() the Threads, we are able to get each element by reference (&$thread), and modify them.

- We are able to create new array elements and assign values to them, like this:

 $thread['username'] = $post['User']['username'];.
Now, we need to create the View that will be for the content section of this page. 
Forum View
In the Controller we passed this: $vars['content_view'] = ‘forum’;

So the Template will look for a View named ‘forum’.

Create: system/application/views/forum.php






	
		
		( replies)
	

	
		Author: ,
		Posted: 
	




There is nothing new here. Just putting the data into HTML.
The Result

Go to the Home Page and click on the first Forum.

You should see this:

Seems to be working!
Stay Tuned
We built another page in our project and explored two more important subjects along the way. Stay tuned for the next article, there is still plenty of work to do  
Thank you for reading. 

		

			"CodeIgniter and Doctrine from Scratch" Series:
			
				Day 1: Install and Setup
				Day 2: The Basics
				Day 3: User Signup Form
				Day 4: User Login
				Day 5: Database CRUD
				Day 6: Models with Relationships
				Day 7: Fixtures & Forum List
				Day 8: Hooks, Profiling & DQL
				Day 9: Templates & Data Hydrators
				Day 10: Pagination
				Day 11: Record Hooks
				Day 12: ...coming soon

CodeIgniter and Doctrine from scratch. Day 8 – Hooks, Profiling & DQL

Burak — Fri, 04 Dec 2009 04:52:10 +0000

In this article we are going to look at 3 main subjects: Hooks (with CodeIgniter), Doctrine Profiling and DQL. And we are going to see how we can use these to optimize some of our database interactions.

"CodeIgniter and Doctrine from Scratch" Series:

Before we start going into Hooks, Profiling and DQL, let’s make a small addition to our Message Board home page.

User Controls

In Message Boards, there is usually a section in the top right, with user specific info and links. I am not sure if there is a better name for it, but I’m going to call it “User Controls”.

On the CodeIgniter Forums it looks like this:

And if you are not logged in, it looks like this:

Now we are going add something similar, but simpler, to our Message Board.

Home View

Edit: system/application/views/home.php




	
	Home
	





	
		
			Hello, username; ?> 

			
		
			 |
			
		
	

	CI+Doctrine Message Board

	

		

			title; ?>

			Forums as $forum): ?>

				

					
						id, $forum->title) ?>
						(Threads->count(); ?> threads)
					

					
						description; ?>

We just added the highlighted lines.

Line 13: We are using the Current_User class, to see if the user is logged in. If they are logged in, we will get an instance of the User Model. If not, it will return false.

Lines 15-16: We display the username, and link to the Logout Controller.

Lines 18-19: This section is for people who are not logged in. We link to the Login Controller and Signup Controller.

So we pretty much have just utilized Models and Controllers we have built before.

We need to make a small addition to the css.

Edit: css/style.css
Add this to the end of the file.

/* USER CONTROL BOX -------------------------------*/
.user_controls {
	float: right;
	text-align: right;
}

Testing

Go to: http://localhost/ci_doctrine/

The links are showing up at the top right corner.

Click Login.
Login as Testuser:mypass .

Now we can see the username and the Logout link.

We will add more features to this later in other tutorials.

Profiling with Doctrine

Using Doctrine, our code is cleaner, smaller and easier to read and maintain. But it is sometimes a good idea to look at a few things that are going on behind the scenes.

For example, Doctrine executes several SQL queries for us, while we use our Models. It would be nice to know what these queries are, so we can see if there is more room for optimization. This can be accomplished by Profiling.

For this, we are going to be using a Doctrine component called Doctrine_Connection_Profiler.

Profiling the Home Page

Let’s look at what queries are executed on the home page. We are going to make a quick and dirty test for now. Later in the article we’ll make a more re-usable version.

There is going to be lots of new code here, but I will explain them line by line:

Edit: system/application/controllers/test.php

getConnections() as $conn) {
			$conn->setListener($profiler);
		}

		// copied from home controller
		$vars['categories'] = Doctrine::getTable('Category')->findAll();

		$this->load->view('home', $vars);

		// analyze the profiler data
		$time = 0;
		$events = array();
		foreach ($profiler as $event) {
		    $time += $event->getElapsedSecs();
			if ($event->getName() == 'query' || $event->getName() == 'execute') {
				$event_details = array(
					"type" => $event->getName(),
					"query" => $event->getQuery(),
					"time" => sprintf("%f", $event->getElapsedSecs())
				);
				if (count($event->getParams())) {
					$event_details["params"] = $event->getParams();
				}
				$events []= $event_details;
			}
		}
		print_r($events);
		echo "\nTotal Doctrine time: " . $time  . "\n";
		echo "Peak Memory: " . memory_get_peak_usage() . "\n";
	}

}

Lines 15-17 are just copied from the home Controller. Before that, we set up the Profiler, and after that we look at the data gathered by the Profiler.

Lines 9-12: First we create a Profiler object. Then we attach it to every Doctrine connection. In our case, it will be just one connection. Now it’s ready to listen and record all Doctrine events.

Line 22: The Profiler object let’s us loop through it and get each Event object. Events can be executed queries and also other things like fetching row data etc.. But we are only going to look at query events.

Lines 20,23 and 37: Each Event has information on how much time it took. So we will add them up in $time variable and display it at the end.

Line 24: We are only interested in SQL queries. These can be types ‘query’ or ‘execute’. If a query has assigned parameters (for example ‘WHERE id = ?’), then it is of type ‘execute’, otherwise it is ‘query’.

Lines 25-32: We create an array ($event_details) with information about the query. The type, the query SQL, and the time it took to run. Also if there were any parameters, we add that too.

Lines 33 and 36: We add it all into the $events array, and just dump it at the end with print_r().

Line 38: We use the memory_get_peak_usage() PHP function to find out what the maximum memory usage was during the script execution.

Go to: http://localhost/ci_doctrine/test/home_profiler
View Source:

As you can see, there were 9 queries executed by Doctrine. That seems too many. This happens because of the way Doctrine does ‘lazy loading’. It fetches data from the database as we access the objects and their parameters.

Later in the article, we are going to see how we can optimize this with DQL.

Let’s see how we can use the Profiler for the entire application, in a re-usable way. For that, we’re going to look at CodeIgniter Hooks.

CodeIgniter Hooks

With Hooks, we can tell CodeIgniter to perform an operation, at a given point in the application flow.

For example, we are going to initialize the Profiler, before any Controller function is called.

Enabling Hooks

Hooks are disabled by default, so we must first enable them.

Edit: system/application/config/config.php

// ...

/*
|--------------------------------------------------------------------------
| Enable/Disable System Hooks
|--------------------------------------------------------------------------
|
| If you would like to use the "hooks" feature you must enable it by
| setting this variable to TRUE (boolean).  See the user guide for details.
|
*/
$config['enable_hooks'] = TRUE;

// ...

Just changed it from FALSE to TRUE. Now we can use Hooks.

Creating a Profiler Hook

Let’s create the functions that will be called for this hook.

Create: system/application/hooks/doctrine_profiler_hooks.php

getConnections() as $conn) {
			$conn->setListener(self::$profiler);
		}

	}

	public function profiler_end() {

		// analyze the profiler data
		$time = 0;
		$events = array();
		foreach (self::$profiler as $event) {
		    $time += $event->getElapsedSecs();
			if ($event->getName() == 'query' || $event->getName() == 'execute') {
				$event_details = array(
					"type" => $event->getName(),
					"query" => $event->getQuery(),
					"time" => sprintf("%f", $event->getElapsedSecs())
				);
				if (count($event->getParams())) {
					$event_details["params"] = $event->getParams();
				}
				$events []= $event_details;
			}
		}

		$output = "<"."?php  if ( ! defined('BASEPATH')) exit('No direct script access allowed'); ?".">\n\n";
		$output .= print_r($events,1);
		$output .= "\nTotal Doctrine time: " . $time  . "\n";
		$output .= "Peak Memory: " . memory_get_peak_usage() . "";

		file_put_contents(BASEPATH."/logs/doctrine_profiler.php", $output);
	}
}

The code is mostly the same as before. This time we are storing the $profiler as a static variable in this class. Also, we are writing the output to a log file instead of dumping it into the browser.

Adding the Hooks

Now we need to add the hooks to the config so they get executed.

Edit: system/application/config/hooks.php

 'Doctrine_Profiler_Hooks',
	'function' => 'profiler_start',
	'filename' => 'doctrine_profiler_hooks.php',
	'filepath' => 'hooks',
	);

$hook['post_controller'][] = array(
	'class'    => 'Doctrine_Profiler_Hooks',
	'function' => 'profiler_end',
	'filename' => 'doctrine_profiler_hooks.php',
	'filepath' => 'hooks',
	);

/* End of file hooks.php */
/* Location: ./system/application/config/hooks.php */

So we store the hooks inside the $hook array. The index of the array is name of the hook. In this case we used the ‘post_controller_constructor’ and ‘post_controller’ Hooks.

The array structure should be easy to understand. We point to the class name, function, file path, file name, so that CodeIgniter can find our code for execution.

(Note: I would have preferred to use the “pre_controller” Hook, because it happens before even the Controller constructor is called. However, the plug-ins are not initialized at that point, including Doctrine, so we need to use “post_controller_constructor” instead.)

Testing

Go to: http://localhost/ci_doctrine/

You should just see the homepage with no errors. If you are getting file access errors, make sure the system/logs folder is writable.

Open: system/logs/doctrine_profiler.php

You should see something like this:

Let’s see how we can optimize this and reduce the number of queries executed.

Optimizing with DQL

In the Day 5 – CRUD article, we had a first look at DQL. Now we are going to use it in our application.

If you are familiar with the CodeIgniter Active Records class, there are some similarities. However DQL is much more powerful.

Reducing the Number of Queries

Edit: system/application/controllers/home.php

findAll();
		$vars['categories'] = Doctrine_Query::create()
			->select('c.title, f.title, f.description')
			->from('Category c, c.Forums f')
			->execute();

		$this->load->view('home', $vars);
	}	

}

We just commented out the findAll() line, and added a DQL call instead.

In the select() call we specify which fields we want to fetch.

In the from() call, we put the Models and use short aliases for them (c and f). Note that, we used c.Forums instead c.Forum, even though the Model was named Forum. This is because we are joining two models here, and in the Category Model definition, we referred to the Forum model as Forums:

hasColumn('title', 'string', 255);
	}

	public function setUp() {
		$this->hasMany('Forum as Forums', array(
			'local' => 'id',
			'foreign' => 'category_id'
		));
	}
}

It was just more suitable to name in plural since it’s a one-to-many relationship.

Another thing to note is that we did not specify an ON clause in DQL. Normally when you join tables in SQL, you would specify the columns you are joining on. But since our model definitions know how these relationships are set up, ON clause is not necessary in this case.

Finally, we run execute() to fetch the Doctrine_Collection object.

Let’s load the home page again, and then look at the profiler output.

First go to: http://localhost/ci_doctrine/
Then open: system/logs/doctrine_profiler.php

You should see something like this:

Now we went down to 7 queries instead of 9. However, there is still room for improvement.

Getting Count

Currently, most of these queries are caused by the count() call in our Home View.

(Threads->count(); ?> threads)

Now we are going to fetch the thread count with DQL so that these extra queries do not need to run.

Edit: system/application/controllers/home.php

findAll();
		$vars['categories'] = Doctrine_Query::create()
			->select('c.title, f.title, f.description')
			->addSelect('t.id, COUNT(t.id) as num_threads')
			->from('Category c, c.Forums f')
			->leftJoin('f.Threads t')
			->groupBy('f.id')
			->execute();
		$this->load->view('home', $vars);
	}	

}

Highlighted lines are where the changes are.

Line 11: Now we are selecting from the Threads Model too, so we can count them. I could have added the ‘Threads’ model into the from() call in Line 10. But I wanted to demonstrate another way you can do joins in DQL. There is also innerjoin() if you need it.

Line 9: COUNT(t.id) will give us the number of threads. I could have added this into the select() in Line 8, but for demonstration purposes again, I used the addSelect() function.

Line 12: Since we want individual Forums returned, and also are counting the Threads per Forum, we are grouping the results by the Forum id field.

If you wanted to do the same thing in raw SQL, the query would look like this:

SELECT c.id, c.title, f.id, f.title, f.description, COUNT(t.id) AS num_threads FROM category c LEFT JOIN forum f ON c.id = f.category_id LEFT JOIN thread t ON f.id = t.forum_id GROUP BY f.id

One More Change

Now we need to do one more change. Since we are going to use the returned ‘num_threads’ value instead of calling $forum->Threads->count(), we need to change a line in the Home View.

Edit: system/application/views/home.php around line #37
Just change the highlighted line.




	
		id, $forum->title) ?>
		(Threads[0]->num_threads; ?> threads)
	

	
		description; ?>

At the first glance, the structure might seem a bit odd. Why not ‘$forum->Threads->num_threads’? or even ‘$forum->num_threads’?

This has to do with the way the query is structured. We called COUNT() on the Threads.id field. Therefore the returned data belongs to the Threads relationship, and not to the $forum object directly.

Also, the relationship is one-to-many. Therefore $forum->Threads is a Doctrine_Collection by default, instead of a Doctrine_Record. So we treat it like an array, and add the [0] index first before we can get the data in num_threads.

The result is: $forum->Threads[0]->num_threads

If you are ever unsure about the structure of the returned Doctrine_Collection object, you can convert it to an array using toArray(true) and dump it on the screen. Passing ‘true’ makes it ‘deep’, otherwise you only get the outermost object.

For example, if you do this:

$vars['categories'] = Doctrine_Query::create()
	->select('c.title, f.title, f.description')
	->addSelect('COUNT(t.id) as num_threads')
	->from('Category c, c.Forums f')
	->leftJoin('f.Threads t')
	->groupBy('f.id')
	->execute();
print_r($vars['categories']->toArray(true));

You can get an output like this:

Profile Again

Let’s look at the profiling results again to see how the new DQL performed.

First go to: http://localhost/ci_doctrine/
Then open: system/logs/doctrine_profiler.php

You should see something like this:



Array
(
    [0] => Array
        (
            [type] => query
            [query] => SELECT c.id AS c__id, c.title AS c__title, f.id AS f__id, f.title AS f__title, f.description AS f__description, COUNT(t.id) AS t__0 FROM category c LEFT JOIN forum f ON c.id = f.category_id LEFT JOIN thread t ON f.id = t.forum_id GROUP BY f.id
            [time] => 0.000493
        )

    [1] => Array
        (
            [type] => execute
            [query] => SELECT u.id AS u__id, u.username AS u__username, u.password AS u__password, u.email AS u__email, u.created_at AS u__created_at, u.updated_at AS u__updated_at FROM user u WHERE u.id = ? LIMIT 1
            [time] => 0.000354
            [params] => Array
                (
                    [0] => 2
                )

        )

)

Total Doctrine time: 0.011896848678589
Peak Memory: 6010440

Nice, we are all the way down to 2 queries!

The first one is for fetching all Categories, their Forums, and Thread counts all at once. And the second query was done by the Current_User class for getting user details. You can’t go much lower than this.

Conclusions

I admit that our code became a little more complicated when we switched from using findAll() to DQL. But if your web application is expecting a significant amount of traffic, you might need to utilize such optimizations. Also, with DQL you can achieve more complicated queries that would not be practical with the magic functions like findAll() or findBy*().

Optimization is a debatable subject. Some prefer to do it early, in small steps. Some prefer to do it all the way at the end of development. But as you gain experience, your initial code tends to be more optimized in the first place, and may not need many changes later on.

I guess the point is, using an ORM like Doctrine does not magically optimize your database interactions. You still need to put an effort into it.

Stay Tuned

Thank you for reading. Learning more about DQL was an important step, as it is an integral part of Doctrine. Also, Hooks and Profiling gave us an opportunity to look at what is going on behind the scenes.

And thank you for all the encouraging comments. It makes writing these articles even more enjoyable.

"CodeIgniter and Doctrine from Scratch" Series:

Top 20+ MySQL Best Practices

Burak — Wed, 25 Nov 2009 18:05:32 +0000

Nettuts+ just published my article!

http://net.tutsplus.com/tutorials/other/top-20-mysql-best-practices/

Database operations often tend to be the main bottleneck for most web applications today. It’s not only the DBA’s (database administrators) that have to worry about these performance issues. We as programmers need to do our part by structuring tables properly, writing optimized queries and better code. Here are some MySQL optimization techniques for programmers.

CodeIgniter and Doctrine from scratch Day 7 – Fixtures & Forum List

Burak — Fri, 20 Nov 2009 08:33:17 +0000

Today we will continue building our Message Board project. First we will start building the Home Page, which will be a Forum List. Then we will learn about Doctrine Data Fixtures. This will help us create some test data to play with.

"CodeIgniter and Doctrine from Scratch" Series:

First, Some Styling

Before we get started, let’s add some style so that pages look somewhat decent. Just copy-paste, and don’t read it. CSS is not our focus today.

Edit: css/style.css

body {
	font-family: "Trebuchet MS",Arial;
	font-size: 14px;
	background-color: #212426;
	color: #B9AA81;
}

a {
	color: #FFF;
}

a:hover {
	color: #B9AA81;
}

input, textarea, select {
	font-family:inherit;
	font-size:inherit;
	font-weight:inherit;
}

/* FORUMS -----------------------------------------*/

div.forums {
	width: 720px;
	margin: auto;
}

.forums h2 {
	font-size: 16px;
	color: #000;
	padding: 5px 10px 5px 10px;
	margin: 0px;
	background-color: #BBB;
	-moz-border-radius-topleft: 6px;
	-moz-border-radius-topright: 6px;
	-webkit-border-top-left-radius: 6px;
	-webkit-border-top-right-radius: 6px;
}

.forums h3 {
	font-size: 15px;
	margin: 0px;
}

.category {
	margin-bottom: 40px;
}

.forum {
	border-bottom: 1px solid #666;
	padding: 10px;
}

.forum .description {
	font-size: 14px;
}

/* SIGNUP FORM ------------------------------------*/
#signup_form {
	margin-left: auto;
	margin-right: auto;
	width: 360px;
	font-size: 16px;
}

#signup_form .heading {
	text-align: center;
	font-size: 22px;
	font-weight: bold;
	color: #B9AA81;
}

#signup_form form {
	background-color: #B9AA81;
	padding: 10px;
	border-radius: 8px;
	-moz-border-radius: 8px;
	-webkit-border-radius: 8px;
}

#signup_form form label {
	font-weight: bold;
	color: #11151E;
}

#signup_form form input[type=text],input[type=password] {
	width: 316px;
	font-weight: bold;
	padding: 8px;
	border: 1px solid #FFF;
	border-radius: 4px;
	-moz-border-radius: 4px;
	-webkit-border-radius: 4px;
}

#signup_form form input[type=submit] {
	display: block;
	margin: auto;
	width: 200px;
	font-size: 18px;
	background-color: #FFF;
	border: 1px solid #BBB;

}

#signup_form form input[type=submit]:hover {
	border-color: #000;
}

#signup_form .error {
	font-size: 13px;
	color: #690C07;
	font-style: italic;
}

Ok, now we’re ready to get more coding done!

The Home Page

We are about to work on the Controller and the View for our Home Page (i.e. Forum List). We want this page to show all of the Forums broken down by Categories.

Home Controller

Edit: system/application/controllers/home.php

findAll();

		$this->load->view('home', $vars);
	}	

}

As mentioned before, variables are passed to a View in an array, and the array indexes become variable names. In other words, $vars['categories'] becomes $categories inside the View.

Doctrine::getTable(‘Category’)->findAll(); gives us all of the Category records, in the form of a Doctrine_Collection object.

Home View

(I’m going build this page in a few steps)

Edit: system/application/views/home.php

First we make a blank page, with a container div and a heading:




	
	Home
	





	CI+Doctrine Message Board

Next, we loop thru the $categories object, and display titles for each Category:




	
	Home
	





	CI+Doctrine Message Board

	

		

			title; ?>

Note: $categories is a Doctrine_Collection object here, but it can be treated like an array. So we can use foreach on it.

Now we are going to show each Forum, their descriptions, and number of Threads.




	
	Home
	





	CI+Doctrine Message Board

	

		

			title; ?>

			Forums as $forum): ?>

				

					
						id, $forum->title) ?>
						(Threads->count(); ?> threads)
					

					
						description; ?>

As you can see, getting all Forums under a Category is as easy as calling $category->Forums. And again, we can treat it as an array and loop thru it.

Line 26: We are creating a link to the Forum. It will link to a Controller named Forums and pass the id in the url. And the link text is the Forum title.

Note: In CodeIgniter, Controllers and Models cannot have the same name. That’s why I linked to ‘forums’ instead of ‘forum’. Some people might prefer ‘view_forum’ or ‘show_forum’ etc…

Line 27: This is the first time we are using count(). That’s how we get the number of Threads that belong to that Forum object.

The Result

Go to: http://localhost/ci_doctrine/

You will see this:

Looks nice. But the links are broken since we haven’t created the Forums Controller (i.e. Forum Page) yet.

Now, we could go ahead and build the Forum Page, but it’s just not going to look very good since we have no Threads or Posts whatsoever. This is a great time to start talking about Data Fixtures.

Doctrine Data Fixtures

What are Data Fixtures?

“Data fixtures are meant for loading small sets of test data through your models to populate your database with data to test against.” (from here).

This will do the job for filling the database with some data, so we can do proper testing as we develop our project.

In the last article, we created a Test Controller for inserting some data. That worked well for this tutorial, and we saw some code examples along the way. But on a real development environment, it’s better to just use Data Fixtures.

Creating Fixtures

First, we need to have a place to put our Fixtures. You can put this folder anywhere, but I would like to create it directly under the applications folder.

Create Folder: system/application/fixtures
Create: system/application/fixtures/data.yml

That’s right, we are creating a YAML file. Don’t worry if you are not familiar with this file format.

We are going to start small with an example:

User:
  Admin:
    username: Administrator
    password: testing
    email: programming@gmail.com
  Test:
    username: TestUser
    password: mypass
    email: test@test.com

Even if you are not familiar with YAML, the structure is easy to understand.
This code just creates 2 User records.

Note: I used 2 spaces for indentation, but it can be any number of spaces. And Tabs do NOT work.

First line is the name of the Model we are loading data for.
Line 2 and 6: These are just names for these records. They can be anything. We can use them later in the fixture to reference these records.
The rest should be obvious. We are assigning data to each field for these records.

Now, we need to load this fixture into the database.

Edit: system/application/controllers/doctrine_tools.php


		
		

';

		if ($this->input->post('action')) {

			Doctrine_Manager::connection()->execute(
				'SET FOREIGN_KEY_CHECKS = 0');

			Doctrine::loadData(APPPATH.'/fixtures');
			echo "Done!";
		}
	}

}

We added a function named load_fixtures() to this Controller.

Doctrine:loadData() does the work. Every time it is called, it will purge existing data from the tables, and load the Data Fixtures from the given path. If you don’t want the table purge to happen, you need to pass a second argument as true.

(I also had to disable FOREIGN_KEY_CHECKS to avoid some foreign key related errors during the purge.)

Go to: http://localhost/ci_doctrine/doctrine_tools/load_fixtures and click the button.
Now check the user table in phpmyadmin.

Now that everything seems to be working, let’s expand our fixture so we have more data to work with.

Edit: system/application/fixtures/data.yml

User:
  Admin:
    username: Administrator
    password: testing
    email: programming@gmail.com
  Test:
    username: TestUser
    password: mypass
    email: test@test.com
  Foo:
    username: Foobar
    password: mypass
    email: test2@test2.com

Forum:
  Forum_1:
    title: Introduce Yourself!
    description: >
      Use this forum to introduce yourself to the CodeIgniter community,
      or to announce your new CI powered site.
  Forum_2:
    title: The Lounge
    description: >
      CodeIgniter's social forum where you can discuss anything not related
      to development. No topics off limits... but be civil.
  Forum_3:
    title: CodeIgniter Discussion
    description: This forum is for general topics related to CodeIgniter.
  Forum_4:
    title: Code and Application Development
    description: >
      Use the forum to discuss anything related to
      programming and code development.
  Forum_5:
    title: Ignited Code
    description: >
      Use this forum to post plugins, libraries, or other code contributions,
      or to ask questions about any of them.

Category:
  Lounge:
    title: The CodeIgniter Lounge
    Forums: [Forum_1, Forum_2]
  Dev:
    title: CodeIgniter Development Forums
    Forums: [Forum_3, Forum_4, Forum_5]

Thread:
  Thread_1:
    title: Hi there!
    Forum: Forum_1
  Thread_2:
    title: Greetings to all
    Forum: Forum_1

Post:
  Post_1:
    Thread: Thread_1
    User: Test
    created_at: 2009-11-20 01:20:30
    content: >
      Hello everyone! My name is Test, and I go to school at
      Test Institute of Technology in the US.
      I just found CodeIgniter some time last week and have been
      reading through the documentation trying to get myself acquainted.

      Hopefully the forums will be a great help! I already have some questions.
      Thanks!
  Post_2:
    Thread: Thread_1
    User: Admin
    created_at: 2009-11-20 02:15:33
    content: Welcome Test! Nice to meet you.
  Post_3:
    Thread: Thread_2
    User: Foo
    created_at: 2009-11-19 12:14:50
    content: I am new here. Just wanted to say hi.

This is just a bunch of structured data, nothing complicated. For each Model, we create a few records. And we have a few new things to mention:

Line 18: Here you can see the syntax for adding a long string value in multiple lines.
Line 51: We are setting up the relationships between records. This line says Thread_1 belongs to Forum_1.
Line 43: Again, we are setting up relationships, but this time we are assigning multiple records, and you see the syntax for that.

Go to: http://localhost/ci_doctrine/doctrine_tools/load_fixtures and click the button.
And, go to phpmyadmin and look at all the tables.

We just created 15 records!

See the Results

Go to: http://localhost/ci_doctrine/

We can see all the Categories and Forums we just created. Also there are 2 Threads now, as we can see from the count.

Stay Tuned

Our Message Board is starting to take shape. Meanwhile we learned about a new concept called Data Fixtures, which is very helpful during the development process.

In the next tutorials we will go deeper into the project and keep building more functional pages.

See you next time!

"CodeIgniter and Doctrine from Scratch" Series:

CodeIgniter and Doctrine from scratch Day 6 – Models with Relationships

Burak — Fri, 13 Nov 2009 06:57:27 +0000

In this episode of the series, we will continue building our Message Board project. First we will have a quick overview of Doctrine Model Relationships. Then we will create Models for our Message Board, such as: Forums, Threads, Posts etc… with proper relationships. Finally we will learn how to add data into such Models.

"CodeIgniter and Doctrine from Scratch" Series:

Doctrine Model Relationships (a quick overview)

One of the key features of Doctrine is the handling of Relationships between Models. At this point in our project, we will start utilizing it.

On a typical Message Board:

There are Forums
Forums have Threads
Threads have Posts
Users have Posts

We will learn how to define these relationships in our Models. Doctrine supports the following types of relationships:

One to Many (or Many to One)
One to One
Many to Many
Tree Structure
Nest Relations

Today we will be talking about only the first two.

Foreign Keys

To setup relationships between models (and tables in the database), we need to have certain fields in our tables. These are used as Foreign Keys.

For example, if each Post belongs to a User, we need a user_id field in the Post table. We can specify this in our model:

class Post extends Doctrine_Record {

	public function setTableDefinition() {
		$this->hasColumn('content', 'string', 65535);
		$this->hasColumn('user_id', 'integer');
	}

}

But to specify the type of relationship, we are going to have to do more than that.

One to Many Relationships

Just like the name suggests, this creates a relationship between one instance of a Model and multiple instances of another Model.

For example: one User has many Posts.

In Doctrine, this kind of relationship is setup using the hasOne() and hasMany() functions.

Post Example:

class Post extends Doctrine_Record {

	public function setTableDefinition() {
		$this->hasColumn('content', 'string', 65535);
		$this->hasColumn('user_id', 'integer');
	}

	public function setUp() {
		$this->hasOne('User', array(
			'local' => 'user_id',
			'foreign' => 'id'
		));
	}

}

hasOne() says that the Post is associated with one User. The first parameter is the Model name and the second parameter is an array that sets the foreign keys.

It links the two Models by the user_id field in the local Model (i.e. Post), with the id field in the foreign Model (i.e. User).

Now we can access the User object for a post like this: $post->User. We’ll see more of that later.

User Example:

class User extends Doctrine_Record {

	public function setTableDefinition() {
		$this->hasColumn('username', 'string', 255, array('unique' => 'true'));
		$this->hasColumn('password', 'string', 255);
	}

	public function setUp() {
		$this->hasMany('Post as Posts', array(
			'local' => 'id',
			'foreign' => 'user_id'
		));
	}
}

On this side of the relationship, there are no additional fields for the foreign key. But we still define it by the hasMany() call.

The first parameter looks a bit different this time. When we say Post as Posts, we link to the Model named Post, but we name the property Posts.

This way we are going to access it like $user->Posts, instead of $user->Post. This is just a matter of preference, because it sounds better.

Note: As a rule of thumb, the Model that has the hasOne() call is the one with the foreign key field. (Post.user_id in this case).

One to One Relationships

This type of relationship is used when each Model is linked to only one instance of the other Model.

For example, if you have separate Models/Tables for User and Email, and if you want each User to have only one Email, you might use this.

The syntax is exactly the same as the One to Many Relationships, but this time both Models call the hasOne() function, instead of hasMany().

for more info

This is all we needed to know to continue our project for now. But if you want to find out about all types of relationships in Doctrine, you can read the whole documentation section on this subject here.

Let’s Create Some Models

Let’s use what we just learned to create our new Models.

Note: I would like to build this project similar to the CodeIgniter Message Board. They also seem to have Categories, that contain multiple Forums, so we are going to create a Model for that too.

Category Model

Create: system/application/models/category.php

hasColumn('title', 'string', 255);
	}

	public function setUp() {
		$this->hasMany('Forum as Forums', array(
			'local' => 'id',
			'foreign' => 'category_id'
		));
	}
}

Looks simple. We have a Category Model that has a title, and can have many Forums. Also we are expecting that the Forum Model to have a field named category_id.

Forum Model

Create: system/application/models/forum.php

hasColumn('title', 'string', 255);
		$this->hasColumn('description', 'string', 255);
		$this->hasColumn('category_id', 'integer', 4);
	}

	public function setUp() {
		$this->hasOne('Category', array(
			'local' => 'category_id',
			'foreign' => 'id'
		));
		$this->hasMany('Thread as Threads', array(
			'local' => 'id',
			'foreign' => 'forum_id'
		));
	}

}

As expected, we have a category_id field for the foreign key.

Also we have 2 relationships now. First one is with Category Model, as Forums have (or belong to) a single Category. The second one is with Thread Model. Each Forum can have many Threads.

Thread Model

Create: system/application/models/thread.php

hasColumn('title', 'string', 255);
		$this->hasColumn('forum_id', 'integer', 4);
	}

	public function setUp() {
		$this->hasOne('Forum', array(
			'local' => 'forum_id',
			'foreign' => 'id'
		));
		$this->hasMany('Post as Posts', array(
			'local' => 'id',
			'foreign' => 'thread_id'
		));
	}

}

Post Model

Create: system/application/models/post.php

hasColumn('content', 'string', 65535);
		$this->hasColumn('thread_id', 'integer', 4);
		$this->hasColumn('user_id', 'integer', 4);
	}

	public function setUp() {
		$this->actAs('Timestampable');
		$this->hasOne('Thread', array(
			'local' => 'thread_id',
			'foreign' => 'id'
		));
		$this->hasOne('User', array(
			'local' => 'user_id',
			'foreign' => 'id'
		));
	}

}

Notice this time we have 2 foreign keys. Because a Post belongs to a Thread, and also belongs to a User.

User Model

We already have this Model, we are just making changes.

Edit: system/application/models/user.php

setTableName('user');
		$this->actAs('Timestampable');
		$this->hasMutator('password', '_encrypt_password');

		$this->hasMany('Post as Posts', array(
			'local' => 'id',
			'foreign' => 'user_id'
		));
	}
//...
}

Create the Tables

Remember our Controller that creates Tables from Models? It’s time to use that again.

Go to: http://localhost/ci_doctrine/doctrine_tools/create_tables
Press the button, and it should create the tables.
Look at phpmyadmin at: http://localhost/phpmyadmin.

Looks great!

Now let’s see how we can add some data using these Models.

Creating Records

We are going to write a quick test controller to demonstrate how we can add data.

Create: system/application/controllers/test.php

title = "The CodeIgniter Lounge";
		$category->save();

		$forum = new Forum();
		$forum->title = "Introduce Yourself!";
		$forum->description = "Use this forum to introduce yourself to the CodeIgniter community, or to announce your new CI powered site.";

		$forum->Category = $category;

		$forum->save();
	}

}

Do you see how intuitive it is?

$forum->Category represents the relationship that the Forum object has with the Category Model. We can directly assign a Category object to it to link them.

Let’s expand this so we have a bit more data.

Edit: system/application/controllers/test.php

title = "The CodeIgniter Lounge";

		$forum = new Forum();
		$forum->title = "Introduce Yourself!";
		$forum->description = "Use this forum to introduce yourself to the CodeIgniter community, or to announce your new CI powered site.";
		// add category to the forum
		$forum->Category = $category;

		$forum2 = new Forum();
		$forum2->title = "The Lounge";
		$forum2->description = "CodeIgniter's social forum where you can discuss anything not related to development. No topics off limits... but be civil.";

		// you can also add the other way around
		// add forum to the category
		$category->Forums []= $forum2;

		// a different syntax (array style)

		$category2 = new Category();
		$category2['title'] = "CodeIgniter Development Forums";

		$forum3 = new Forum();
		$forum3['title'] = "CodeIgniter Discussion";
		$forum3['description'] = "This forum is for general topics related to CodeIgniter";

		$forum4 = new Forum();
		$forum4['title'] = "Code and Application Development";
		$forum4['description'] = "Use the forum to discuss anything related to programming and code development.";

		$category2['Forums'] []= $forum3;
		$category2['Forums'] []= $forum4;

		// flush() saves all unsaved objects
		$conn = Doctrine_Manager::connection();
		$conn->flush();

		echo "Success!";

	}

}

We just created 2 categories, and 2 forums in each of them, in a few different ways.

Line 21: We add a Forum to the Category, instead of the other way around. But this time, since $category->Forums contains multiple Forums, we push to it like you would to an array, instead of direct assignment like on line 13.
Lines 25-37: Here you can see how we can access all elements of the Doctrine Model objects like array elements. Some people prefer this syntax.
Lines 40-41: Instead of calling save() on every single object, we can just use flush() to save everything.

Let’s test this.

Go to: http://localhost/ci_doctrine/test

You should see the success message:

Success!

Now let’s look at the category table:

You can see our new 2 categories, with id’s 1 and 2. Let’s see if the forums got the correct associations.

Look at the forum table:

Everything looks good! The Forums each have proper category_id’s assigned.

Stay Tuned

Today we learned about one of main features of Doctrine. We were able to create foreign key relationships without using any queries whatsoever! That is one of the nice things about using an ORM like Doctrine. I hope you are able to see how much time you can save by developing like this.

In the next episode we will continue on our project, with a little more CodeIgniter stuff.

See you next time!

"CodeIgniter and Doctrine from Scratch" Series:

CodeIgniter and Doctrine from scratch Day 5 – Database CRUD

Burak — Mon, 09 Nov 2009 14:00:09 +0000

CRUD stands for Create, Read, Update and Delete, the basic operations performed on the database. With regular CodeIgniter setups, most developers would use the Active Record Class for performing such operations. But we are not going to be doing that.

In this episode of the series, I will show you how to perform CRUD with Doctrine.

"CodeIgniter and Doctrine from Scratch" Series:

In Doctrine, there can be multiple ways of accomplishing the same task. This gives you flexibility to pick the best approach suitable for each situation. Therefore we shall explore these different methods for each part of the CRUD.

1. CREATE

The act of inserting new data/records into the database:

Record Object

This is the way we have been creating our user records in the previous tutorials. It’s pretty simple:

$u = new User();

$u->username = 'myuser';
$u->password = 'mypass';

$u->save();

When the save() method is called, the new record is created.

fromArray()

Sometimes you have all the data already in an array. Instead of assigning every value to the record object separately, you can simply use the fromArray() method.

$data = array(
	'username' => 'myuser',
	'password' => 'mypass',
	'email' => 'my@email.com'
);

$u = new User();

$u->fromArray($data);

$u->save();

flush()

When you call the flush() method on the Doctrine_Connection object, all unsaved record objects automatically get saved. And Doctrine performs this in a single transaction.

$u = new User();
$u->username = 'myuser';
$u->password = 'mypass';

$u2 = new User();
$u2->username = 'foouser';
$u2->password = 'foopass';

$conn = Doctrine_Manager::connection();

$conn->flush();

This way you don’t need to call the save() method for each object.

Raw SQL

We can just give a plain SQL query to the Doctrine_Connection object and call the execute() method.

This also supports binding of values to the query (with the usage of ‘?’), which automatically filters against SQL injection.

$data = array('myuser','mypass');

$conn = Doctrine_Manager::connection();

$conn->execute('INSERT INTO user (username, password) VALUES (?,?)',  $data);

2. READ

The act of fetching records from the database.

Most of these are performed on Doctrine_Table objects, which is obtained by calling Doctrine::getTable() and passing the model class name to it.

find()

The find() method fetches a record by the Primary Key value.

$user_id = 1;

$u = Doctrine::getTable('User')->find($user_id);

echo $u->username;

findOneBy*()

This is a magic method. You can simply append the column name, and it will search the table by that column.

For example, to find a user record by username:

$username = 'myuser';

$u = Doctrine::getTable('User')->findOneByUsername($username);

echo $u->username;

It fetches only one record.

findBy*()

Another magic method, which works similarly, but fetches multiple rows. It returns a Doctrine_Collection object.

You can treat this returned object just like an array, to get to the individual record.

(let’s assume we have a column named ‘status’):

$users = Doctrine::getTable('User')->findByStatus('active');

echo $users[0]->username;
echo $users[1]->username;

Even if the actual column name is all lowercase, it can be used as capitalized in that magic function call (status vs. Status).

DQL

This is our first look at DQL in these tutorials. It stands for Doctrine Query Language. It is actually a major feature. Most advanced queries are performed using DQL.

In this example, we first create the query object, and add the components of the query to it. All the method calls can be chained nicely. Finally we execute the query, which returns us a Doctrine_Collection object, like that last example.

$status = 'active';

$q = Doctrine_Query::create()
	->select('username')
	->from('User')
	->where('status = ?', $status)
	->limit(20);

$users = $q->execute();

echo $users[0]->username;
echo $users[1]->username;

We will see many more examples of DQL in our project. But if you want more info right now, there is a long documentation chapter here.

toArray()

A Doctrine_Record object contains a lot of stuff behind the scenes. If you ever try to print_r() that object directly, you will see a long list of data.

However, when you simply want the data of the record, you can convert it to an array with the toArray() call.

$user_id = 1;

$u = Doctrine::getTable('User')->find($user_id);

$u_arr = $u->toArray();

print_r($u_arr);

What you get will be similar to what you get from a mysql_fetch_assoc() call.

3. UPDATE

The act of updating existing records.

Record Object

You can make direct changes to any Doctrine_Record object. Once you call save(), it will perform an UPDATE.

$user_id = 1;

$u = Doctrine::getTable('User')->find($user_id);

$u->password = 'newpassword';

$u->save();

DQL

When you want to update multiple rows at once, the preferred way is to use DQL.

$status = 'active';

$q = Doctrine_Query::create()
	->update('User')
	->set('status', '?', $status)
	->where('id < 10');

$numrows = $q->execute();
echo "$numrows records updated";

The execute() call in this case returns the number of updated rows.

4. DELETE

The act of deleting records from the database.

Record Object

You can simply call the delete() method to delete a Doctrine_Record object directly.

$user_id = 1;

$u = Doctrine::getTable('User')->find($user_id);

$u->delete();

DQL

When deleting multiple records, use DQL.

$q = Doctrine_Query::create()
	->delete('User')
	->where('id < 10');

$numrows = $q->execute();
echo "$numrows records deleted";

The execute() method call will return the number of deleted records.

Stay Tuned

Today, we took a short break from coding our project and explored some important subjects regarding the usage of CRUD with Doctrine. What we learned today will be very useful as we continue building our project in the next tutorials.

See you next time!

"CodeIgniter and Doctrine from Scratch" Series:

Top 10 Reasons Why You Should Use a PHP Framework

Burak — Sat, 07 Nov 2009 01:45:44 +0000

PHP Frameworks have been receiving a lot of attention in the past few years from the web development community. What’s this hype all about?

If you look at PHP Job listings, you will often see “MVC Framework Experience” as one of their requirements. It is becoming one of those must-have skill sets for web developers.

There are pretty good reasons behind all of this. In this article we will explore why you, as a PHP programmer, should be using a PHP Framework.

1. Code and File Organization

Just because you created an “/inc” folder and made a “functions.php” file does not mean your code is organized.

When you setup a PHP Framework, it already has a certain folder structure. It is expected from you to follow the same standards and keep everything organized in a certain way.

Once you get used to this model, you will never want to go back.

Unfortunately for some command line champions that still use vi, this can be a challenge. You will need to work with more files, that are smaller in size. But when you use a decent modern code editor or an IDE, it will be a breeze to browse through your application code and find what you need, quickly.

2. Utilities and Libraries

PHP is a great language for web development and provides countless number of tools and libraries.

However, if you ever try to build a whole website with PHP alone, you will find yourself either hunting down a lot of 3rd party code and libraries, or have to write them yourself.

All top PHP frameworks come with certain Libraries and Helpers, that help you with:

Form Validation
Input/Output filtering
Database Abstraction
Session and Cookie Handling
Email, Calendar, Pagination etc…

The list goes on. Not to mention, there is plenty of plugins provided by the community that you can add to your framework.

3. The MVC Pattern

The famous Model View Controller Pattern dates all the way back to 1979, when a guy named Trygve Reenskaug (a Norwegian computer scientist) first described it.

PHP itself works like a template engine. However, when used irresponsibly, it leads to very ugly and unmaintainable code.

The way the MVC Pattern applies to PHP applications:

Models represent your data structures, usually by interfacing with the database.
Views contain page templates and output.
Controllers handle page requests and bind everything together.

This kind of separation leads to cleaner and more maintainable code.

4. Security

In PHP you can already find many input and output filtering functions to protect your website against certain attacks.

However, manually using these functions can get tiring and you may forget about them every once in a while.

With a framework, most of the work can be done for you automatically. For example in CodeIgniter:

Any value passed to database object gets filtered against SQL injection attacks.
All html generating functions, such as form helpers and url helpers filter the output automatically.
All user input can be filtered against XSS attacks.
Encrypting cookies automatically is only a matter of changing a config option.

5. Less Code & Faster Development

There is of course a learning curve for all PHP Frameworks. But once you get over this hump, you will enjoy the benefits of rapid application development.

You will write less code, which means less time spent typing. You will not have to chase down 3rd party libraries all the time for every new project because most of them will come with the default framework install.

Also, since you are being more organized, it will be much faster to chase down bugs, maintain code, and make changes to existing code.

6. Community Support

All popular PHP Frameworks have great active communities behind them. You can talk to other developers, get help, feedback and also give back to the community yourself.

There are message boards and mailing lists… You can also learn a lot by just browsing the forums and look at what other people are talking about.

7. Job Opportunities

Have you looked at any PHP Job postings lately? Most of them require experience with either Frameworks or a CMS. Follow the demand!

Example from Careerbuilder.com:

Experience with PHP Frameworks greatly increases your job qualifications as a web developer.

8. Performance Tools

One of the main arguments from the naysayers comes in this subject. There is obviously a performance hit when you build a “Hello World” application with a framework vs. plain PHP code.

But those benchmarks are just bad examples. First of all, you should understand that developers are more expensive than servers. Saving time from development and maintenance is likely to outweigh any extra money you need to spend on servers.

Putting all of that aside, you can actually gain performance benefits by using a PHP framework. They come with tools that help you do caching, benchmarks, profiling etc…

Modern frameworks are also great with dynamic loading, as they load code only as needed. Different page requests can load different amount of library code based on what needs to be used.

9. Suitable for Teamwork

The way your project is organized in a PHP Framework also helps you create a suitable environment for teamwork.

You can let your designers work on the Views, database guru work on the Models, let the smart programmer (yourself ) build reusable Libraries and Plugins etc…

Also you can let someone build unit tests, because they come with tools for that too.

10. And It’s Fun!

This might actually be most important point of all. When you have fun doing your work, you will be more productive and happier in general.

If you have been coding plain old PHP for years, and getting really bored with it, getting started with a Framework can give you that crucial morale boost you have been lacking.

It’s like getting a new toy, and being able to build cool things with it. At least that’s how I felt when I first got started with Frameworks. I’m sure many of the web developers have gone through similar experiences.

Conclusion

Using a PHP Framework may or may not be the best choice for you. However, you should always keep an open mind and keep up to date with all the new developments in the web development world.

Frameworks are cool and hot today, and we can’t tell what tomorrow is going to bring. I guess all I’m saying is that they are definitely worth looking into.

CodeIgniter and Doctrine from scratch Day 4 – User Login

Burak — Fri, 06 Nov 2009 07:16:30 +0000

In this episode we are going to build a User Login system following these steps:

- We will build a Login Form View and a Login Controller.
- Learn about some URL Helpers.
- Change the Default Controller.
- Implement User Authentication.
- Learn about Singleton Pattern and use it to improve our code design.
- Learn about the Sessions Library.
- Implement User Logout.

"CodeIgniter and Doctrine from Scratch" Series:

Login Form View

First thing we are going to do is to create the View for the Login Form.

We are going to make this one very similar to the Signup Form we created in the last article.

Create: system/application/views/login_form.php




	
	Login Form
	





	User Login

	

	',''); ?>

	
		Username: 
		
	
	
		Password:

All I did was copy the contents of the signup form, change the page title, remove some form fields and added a link at the bottom to the signup form.

anchor()

On Line 33 in the file above, I used a function named anchor(). This is part of the URL Helper in CodeIgniter. It helps us create links with ease. The first argument is the Controller Name, and the second argument is the Link Text. You can also pass an optional third argument for extra html attributes. The result is:

Create an Account

Style the links

I am just going to make a small addition to the stylesheet so our links look better.

Edit: css/style.css

body {
	font-family: "Trebuchet MS",Arial;
	font-size: 14px;
	background-color: #212426;
	color: #11151E;
}

a {
	color: #FFF;
}

a:hover {
	color: #B9AA81;
}

/* ... */

I only added the highlighted lines.

Link from the Signup Form

Likewise, we will add a link from the Signup Form to the new Login Form.

Edit: system/application/views/signup_form.php




	
	Signup Form
	





	New User Signup

	

	',''); ?>

	
		Username: 
		
	
	
		Password: 
		
	
	
		Confirm Password: 
		
	
	
		E-mail:

I only added the highlighted lines.

Note: We just linked to a Controller named login. This Controller does not exist yet. So let’s create it.

Login Controller

First we are going create a sort of skeleton structure for our new Controller.

Create: system/application/controllers/login.php

load->helper(array('form','url'));
		$this->load->library('form_validation');
	}

	public function index() {
		$this->load->view('login_form');
	}

	public function submit() {

		if ($this->_submit_validate() === FALSE) {
			$this->index();
			return;
		}

		redirect('/');

	}

	private function _submit_validate() {

	}

}

This looks very similar to the submit Controller we created in the last article. The only new thing is the highlighted line.

redirect()

This function is part of the URL Helper. It forwards the surfer to a specified Controller. In this case we only passed ‘/’, which will basically send the surfer to the Home Page or in other words the Default Controller.

So the user will end up at http://localhost/ci_doctrine/.

Test The Login Controller+View

Go here: http://localhost/ci_doctrine/login

Now click the link that says Create an Account.

You should see our old Signup Form page.

Works great!

Default Controller

When someone visits the main page of our website (i.e. there is no controller name in the url), it calls the Default Controller. Right now if you go to http://localhost/ci_doctrine/, you will see this:

Because CodeIgniter is loading a Controller named welcome by default.

Let’s say we would like to have a Default Controller named home instead.

Create: system/application/controllers/home.php


Routes File

Edit: system/application/config/routes.php

Changing just one line:
// ...
$route['default_controller'] = "home";
$route['scaffolding_trigger'] = "";
// ...

That’s it. Now when you go to http://localhost/ci_doctrine/, you will see our controller:
Home Sweet Home!

The Routes File has some other purposes, which we will not get into right now. But you can read more about it here.
User Login (Authentication)
Now that our forms are in place, we need to add authentication functionality to our application.
First I want to show you how to accomplish it in a simple and most common way. Once we cover that, I will show you a better way of handling this.
Authentication with Form Validation

Edit: system/application/controllers/login.php

load->helper(array('form','url'));
		$this->load->library('form_validation');
	}

	public function index() {
		$this->load->view('login_form');
	}

	public function submit() {

		if ($this->_submit_validate() === FALSE) {
			$this->index();
			return;
		}

		redirect('/');

	}

	private function _submit_validate() {

		$this->form_validation->set_rules('username', 'Username',
			'trim|required|callback_authenticate');

		$this->form_validation->set_rules('password', 'Password',
			'trim|required');

		$this->form_validation->set_message('authenticate','Invalid login. Please try again.');

		return $this->form_validation->run();

	}

	public function authenticate() {

		// get User object by username
		if ($u = Doctrine::getTable('User')->findOneByUsername($this->input->post('username'))) {

			// this mutates (encrypts) the input password
			$u_input = new User();
			$u_input->password = $this->input->post('password');

			// password match (comparing encrypted passwords)
			if ($u->password == $u_input->password) {
				unset($u_input);
				return TRUE;
			}
			unset($u_input);
		}

		return FALSE;
	}
}

Highlighted functions have been updated.
First I added some form validation rules inside the _submit_validate() function, like in the last article. But this time I added a Callback rule. Notice on Line 29: callback_authenticate. The format is callback_[function_name].
On Line 34 I set a custom message for this validation rule, in case it fails.
Then I added the function named authenticate. This callback function needs to return TRUE when everything is good, and FALSE when the validation fails.
Lines 43-53: This is where I perform the username and password check for the login. First I attempt to get the User Record searching by the input username. (We learned about the getTable and findOneBy* functions in the last article).
Applying the Mutator to an external value
Remember we added a Mutator to the password field in the last article?
Since the stored passwords are encrypted, I need to apply the same encryption to the user input, before I can compare the two.
That’s why I create a new User object named $u_input. on Line 46 and assigned the input password to it. This is how I trigger the Mutator function on the password that was entered in the form. (If anyone knows a better of doing this, let me know!)
Now the encrypted version of the input password resides in $u_input->password. So I was able to compare it to $u->password.
I also unset the $u_input object, just to make sure it doesn’t get saved as a new record by accident.
Testing the Form
First create a new user by going to the Signup Form at http://localhost/ci_doctrine/signup.
Now go to: http://localhost/ci_doctrine/login and use a wrong login. You should see:

When you use a correct login, you should get forwarded back to the home page.
Home Sweet Home!

Our Login Form works!
Now the Better Way!
I mentioned I was going to change things a bit and show you how to do this in a better way.
What’s wrong with the current method?

I don’t like how the authentication code is all inside the Controller. This is not good for code reusability.
It should be part of the User Model, since it’s directly related to it.
We stored the User Record in a variable named $u. But it’s inside a function and not global. So, if other Controllers need to use it, they can’t.
Turning the object $u directly into a Global Variable would be a bad design decision.
We do not want to store the whole user object inside the session. Doctrine Models have a lot of internal data, which could quickly inflate the size of our session storage. Only thing we are going store in the session is the user_id.

Singleton Pattern to the rescue!
Some of you may not know what Singleton Pattern means. It’s one of the most popular design patterns, and I will show you how we are going to use it.
With this new class I am going to create, we will have a better design for our authentication functionality, and we will also make the User Model instance for the logged in user globally available in our application.
Singleton Pattern for Current User
First let’s build the skeleton:

Create: system/application/models/current_user.php

user
			// ...

		}

		return self::$user;
	}

	public function __clone() {
		trigger_error('Clone is not allowed.', E_USER_ERROR);
	}

}

Now let’s go over the code:

There is a reason I called the class Current_User. Because this static class will always return an instance of the User class, for the current logged in user.
This class does NOT extend Doctrine_Record, because we are not really creating a Doctrine Model.
The $user variable will contain the User object for the logged in user. And we will access it by Current_User::user(). That is the syntax for calling a static class function.
We will never create an instance of this Current_User class, so the constructor is set to private.
We also disallow cloning of this class so the __clone() function triggers an error.

Now I’m going to add a bit more code to make this functional.

Edit: system/application/models/current_user.php

load->library('session');

			if (!$user_id = $CI->session->userdata('user_id')) {
				return FALSE;
			}

			if (!$u = Doctrine::getTable('User')->find($user_id)) {
				return FALSE;
			}

			self::$user = $u;
		}

		return self::$user;
	}

	public static function login($username, $password) {

		// get User object by username
		if ($u = Doctrine::getTable('User')->findOneByUsername($username)) {

			// this mutates (encrypts) the input password
			$u_input = new User();
			$u_input->password = $password;

			// password match (comparing encrypted passwords)
			if ($u->password == $u_input->password) {
				unset($u_input);

				$CI =& get_instance();
				$CI->load->library('session');
				$CI->session->set_userdata('user_id',$u->id);
				self::$user = $u;

				return TRUE;
			}

			unset($u_input);
		}

		// login failed
		return FALSE;

	}

	public function __clone() {
		trigger_error('Clone is not allowed.', E_USER_ERROR);
	}

}

Let’s go over the code in user() method first:

The usage for this function is: Current_User::user() and it returns the User object for the logged in user.
Line 10: We check to see if the user object is already there. If it is, we return it at line 26 . 
Lines 12-17: We load the session library, so we can read/write in the session. If the user is logged in, his id should be stored there. If we don’t see the user_id, it returns FALSE.
We had to use the $CI object to load the session library because this is a static class.
Lines 19-21: Fetch the User object by id. If we can’t, return FALSE. Note that we used a function named find() to look up by id.
Lines 23 and 26: Everything went well, so we store the user object in the static variable $user and return it.

Now, when we call Current_User::user() , we can get the User object as if it’s a global variable. And if it returns false, it means the user is NOT logged in.
Let’s go over the login() method:

I copied most of the code from the login Controller we created earlier. The code is from the authenticate() method.
I added loading of the session library at line 42-43, so I could store the user_id in the session at line 44
I also added line 45. Once the user gets logged in, the $user static variable is set, so it can be returned by the user() function later.

By the way, we just learned how to use Sessions in CodeIgniter. It’s not very complicated. All you need to do is to load the library and you can use the userdata() and set_userdata() function to read and write the variables. You can read more about it here.
Now we can call the static function like this: Current_User::login($username,$password) , and it will take care of the rest.
Phew! I hope that was not very complicated. But I’m sure you will soon  understand why we went through all of that.
Simplified Login Controller
We are about the see the first benefit of creating all that code above.

Edit: system/application/controllers/login.php

Only editing the authenticate() function:
input->post('username'),
									$this->input->post('password'));

	}
}

See how easy that is now?
When we call Current_User::login() it attempts to login the user, and returns TRUE on success. If the login information is incorrect, it returns FALSE. 
Once the user is logged in this way, we can retrieve the User object for the logged in user, anywhere in our application by simply calling Current_User::user().
Also note that we didn’t need to put “$this->load->model(‘Current_User’)” in the code, and we will never have to. The Current_User class will always be globally available in the application, because of the Doctrine autoloader that was registered in the “system/application/plugins/doctrine_pi.php” file.
Logout
Now we are going to let users logout by clicking a link. But first:
Autoloading Libraries
It seems like we are going to be using the Session Library almost everywhere in our application. Let’s have it autoloaded by CodeIgniter so we don’t have to keep calling $this->library->load(‘session’) all the time.

Edit: system/application/config/autoload.php

Find this line:
// ...
$autoload['libraries'] = array('session');
// ...

Let’s also autoload the URL Helper.

Edit: system/application/config/autoload.php

Find this line:
// ...
$autoload['helper'] = array('url');
// ...

Now that’s out of the way.
Logout Controller

Create: system/application/controllers/logout.php

session->sess_destroy();
		$this->load->view('logout');
	}

}

We remove all of the session data by calling $this->session->sess_destroy(). Now the user will no longer be logged in.
Logout View

Create: system/application/views/logout.php




	
	Logout
	
	





	
		You are now logged out.
	
	
		Redirecting you .
	






This logout page will display a short message and redirect the surfer using a meta refresh.
Style Changes
I have made some css changes, so just copy paste the following:

Edit: css/style.css

body {
	font-family: "Trebuchet MS",Arial;
	font-size: 14px;
	background-color: #212426;
	color: #B9AA81;
}

a {
	color: #FFF;
}

a:hover {
	color: #B9AA81;
}

input, textarea, select {
	font-family:inherit;
	font-size:inherit;
	font-weight:inherit;
}

#signup_form {
	margin-left: auto;
	margin-right: auto;
	width: 360px;

	font-size: 16px;

}

#signup_form .heading {
	text-align: center;
	font-size: 22px;
	font-weight: bold;
	color: #B9AA81;
}

#signup_form form {

	background-color: #B9AA81;
	padding: 10px;

	border-radius: 8px;
	-moz-border-radius: 8px;
	-webkit-border-radius: 8px;

}

#signup_form form label {
	font-weight: bold;
	color: #11151E;
}

#signup_form form input[type=text],input[type=password] {
	width: 316px;
	font-weight: bold;
	padding: 8px;

	border: 1px solid #FFF;
	border-radius: 4px;
	-moz-border-radius: 4px;
	-webkit-border-radius: 4px;
}

#signup_form form input[type=submit] {
	display: block;
	margin: auto;
	width: 200px;
	font-size: 18px;
	background-color: #FFF;
	border: 1px solid #BBB;

}

#signup_form form input[type=submit]:hover {
	border-color: #000;
}

#signup_form .error {
	font-size: 13px;
	color: #690C07;
	font-style: italic;
}

Home View
Now we are going to see how easy it is to fetch user information for the logged in user.

Create: system/application/views/home.php




	
	Home
	





	
		Hello username; ?>.
		
	
		New Users: .
		Members: .
	






Home Controller

Edit: system/application/controllers/home.php

load->view('home');
	}	

}

That’s it!
Let’s Test It

Go to: http://localhost/ci_doctrine/logout to make sure you are logged out.

First you will see:

And it will forward you home:


Click the Login link to be forwarded to our Login Form.



Enter a correct login info and you will be redirected home again.

Now you should see:

In this case my username is burak, and it was displayed back to me.
Voila!
Stay Tuned
We covered quite a few new concepts in today’s tutorial. I hope you enjoyed it and learned from it.
In the next tutorial we will explore the CRUD (Create, Read, Update and Delete) functionality with Doctrine in more detail.
See you next time!

		

			"CodeIgniter and Doctrine from Scratch" Series:
			
				Day 1: Install and Setup
				Day 2: The Basics
				Day 3: User Signup Form
				Day 4: User Login
				Day 5: Database CRUD
				Day 6: Models with Relationships
				Day 7: Fixtures & Forum List
				Day 8: Hooks, Profiling & DQL
				Day 9: Templates & Data Hydrators
				Day 10: Pagination
				Day 11: Record Hooks
				Day 12: ...coming soon

CodeIgniter and Doctrine from scratch Day 3 – User Signup Form

Burak — Mon, 02 Nov 2009 20:59:01 +0000

In this episode we are going to build a User Signup Form following these steps:

- We build a “User” Model with Doctrine.
- Learn about Mutators.
- Create tables using Doctrine.
- Remove index.php from CodeIgniter urls
- Build and Style the Signup Form.
- Learn about Helpers, Libraries and how to extend them.
- Form Validation and checking for duplicates.

"CodeIgniter and Doctrine from Scratch" Series:

Let’s build a Doctrine Model

Since we are building a user signup form today, it is best to start with a “User” Model.

Our model will be extending the Doctrine_Record class, which will represent records in a table named “user”.

So let’s make one:

Create a file named user.php under system/application/models
We name the class User, matching the file name.
The class name is capitalized, but the filename is always lowercase. (This is a CodeIgniter rule, rather than Doctrine, but we’re still going go with it for consistency.)
We add a method named setTableDefinition(), which will contain column info.
We also add a method named setUp(), which will contain additional options.

system/application/models/user.php

hasColumn('username', 'string', 255, array('unique' => 'true'));
		$this->hasColumn('password', 'string', 255);
		$this->hasColumn('email', 'string', 255, array('unique' => 'true'));
	}

	public function setUp() {
		$this->setTableName('user');
		$this->actAs('Timestampable');
	}
}

Looks simple right? Now let’s go over the code.

$this->hasColumn()

Structure:

$this->hasColumn($name, $type = null, $length = null, $options = array());

This function call tells Doctrine about the table column structure. Everything except the $name field is optional.

Supported $type‘s are: Boolean, Integer, Float, Decimal, String, Array, Object, Blob, Clob, Timestamp, Time, Date, Enum, Gzip.

$options are passed in an array, as ‘name’ => ‘value’ pairs. We passed an option named unique for 2 columns, which means we will have unique indexes on them.

We don’t need to get into more detail on this, but if you want to read more, read Doctrine docs.

$this->setTableName()

Structure:

$this->setTableName($table_name);

Simply sets the table name the Model will use. This can have a totally different name than the Model.

$this->actAs()

Adds a behavior to the model.

The one we used was Timestampable. It adds 2 fields to the table and manages them. They are called created_at and updated_at. And you guessed it, they keep track of the records create and update times.

Note: When we add this behavior, we don’t need those 2 columns specified inside the setTableDefinition() function.

Adding Mutators

Let’s say we want our password field to be automatically encrypted for security. This is where Mutators come in.

So, make the following changes to our model.

system/application/models/user.php (new code is highlighted)

hasColumn('username', 'string', 255, array('unique' => 'true'));
		$this->hasColumn('password', 'string', 255);
		$this->hasColumn('email', 'string', 255, array('unique' => 'true'));

	}

	public function setUp() {
		$this->setTableName('user');
		$this->actAs('Timestampable');
		$this->hasMutator('password', '_encrypt_password');
	}

	protected function _encrypt_password($value) {
		$salt = '#*seCrEt!@-*%';
		$this->_set('password', md5($salt . $value));
	}
}

First we added a Mutator function named _encrypt_password to the password column.

Then we implemented it as a method inside our Model class.

Note: For mutators to work, auto_accessor_override option needs to be enabled. We have already done it, in our plugin file doctrine_pi.php.

Let Doctrine create the tables

Why create the user table manually ourselves when we can just let Doctrine do it for us.

We will use the Doctrine static class to create our tables like this:

Doctrine::createTablesFromModels();

So let’s create a simple and reusable script that we can rebuild our database with.

Create this controller: system/application/controllers/doctrine_tools.php


		
		

';

		if ($this->input->post('action')) {
			Doctrine::createTablesFromModels();
			echo "Done!";
		}
	}

}

Only pay attention to the highlighted line for now. It simply reads our Doctrine Model class files, and creates tables for them in the database.

I know the code is a bit ugly, but we’re just going to use this controller temporarily as we write our initial models.

First make sure user table does NOT exist. If it does, drop it using phpmyadmin.
Go to: http://localhost/ci_doctrine/index.php/doctrine_tools/create_tables and click the button.
Check out our new table.

Note: The id column got generated automatically. We already have a setting in our doctrine_pi.php plugin file:

// set the default primary key to be named 'id', integer, 4 bytes
Doctrine_Manager::getInstance()->setAttribute(
	Doctrine::ATTR_DEFAULT_IDENTIFIER_OPTIONS,
	array('name' => 'id', 'type' => 'integer', 'length' => 4));

Now let’s do some more CodeIgniter tweaking.

Removing “index.php” from CodeIgniter urls

We would like to have url’s like this:


http://localhost/ci_doctrine/welcome

instead of this:


http://localhost/ci_doctrine/index.php/welcome

Shorter, cleaner and nicer.

follow these steps:

Our web server needs mod_rewrite enabled.
For WAMP users: Left-Click the system tray icon -> Apache -> Apache Modules -> rewrite_module
Create a file named .htaccess under our project folder “ci_doctrine”.
Copy-paste the following:

.htaccess:


    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ /ci_doctrine/index.php/$1 [L]


    ErrorDocument 404 /ci_doctrine/index.php

Now we need to tell CodeIgniter that we’re removing index.php from our url’s.

Edit: system/application/config.php

/*
|--------------------------------------------------------------------------
| Index File
|--------------------------------------------------------------------------
|
| Typically this will be your index.php file, unless you've renamed it to
| something else. If you are using mod_rewrite to remove the page set this
| variable so that it is blank.
|
*/
$config['index_page'] = "";

That’s it!

To make sure it’s working, visit: http://localhost/ci_doctrine/welcome.
You should see the welcome page.

Building the Signup Form

Before we start coding, let’s decide how we’re going to do this

The Game plan

We want a Controller named signup, so the url for the signup form becomes http://localhost/ci_doctrine/signup
We would like this signup controller to load a View named signup_form by default, which will contain the html for the form.
The form will submit to a method named submit inside the signup controller i.e. signup/submit.
From there we need to validate the user input. Display errors if needed.
Finally save the new user to the database using our new Doctrine Model.

“Signup” Controller

Create this file: system/application/controllers/signup.php

load->view('signup_form');
	}

}

Now let’s go over the code.

First we created a constructor method (line 5). This will get called first every time.
Constructors are optional, however there is a reason I decided to create one, which we will see in a bit.
In the constructor, we always must call the parent constructor first (line 6).
In the index() method, (which acts as the default method for the controller), we load a View named signup_form.

“signup_form” View

Create this file: system/application/views/signup_form.php




	
	Signup Form





	New User Signup

For now it’s just a simple HTML file.

Go to: http://localhost/ci_doctrine/signup

You should see the output:

New User Signup

CodeIgniter Helpers

Helpers are located in system/helpers. They contain procedural utility functions that make our lives easier.

In this tutorial, we will be using the url and form Helpers.

They can be loaded like this:

$this->load->helper('url');

Or load multiple helpers at once:

$this->load->helper(array('form','url'));

CodeIgniter Libraries

Libraries are very similar to Helpers, but they tend to be Object Oriented instead.

We will be using the form_validation library, and load it like this:

$this->load->library('form_validation');

Once it’s loaded, we can access it like this:

$this->form_validation->//...

Add them to the controller

Edit: system/application/controllers/signup.php

load->helper(array('form','url'));
		$this->load->library('form_validation');
	}

	public function index() {
		$this->load->view('signup_form');
	}

}

Note: When you load Helpers and Libraries inside the Constructor, they become available in all methods of that Controller. For example, now index() function can use them.
Note2: When Views are loaded, they also can use the Helpers and Libraries that the Controller had loaded.

Form Helper

Now that we have it loaded, let’s use our Form Helper functions.

Edit: system/application/views/signup_form.php




	
	Signup Form





	New User Signup

	

	
		Username: 
		
	
	
		Password: 
		
	
	
		Confirm Password: 
		
	
	
		E-mail:

I highlighted all the different kinds of functions we just called. These functions create the html for our form tags and elements.

Open http://localhost/ci_doctrine/signup

And in the source code you can see:




	
	Signup Form





	New User Signup

	

	
		Username: 
			
	
		Password: 
			
	

		Confirm Password: 
			
	
		E-mail:

Let's give it Style

Create a folder named css directly under our project folder ci_doctrine
Create file: css/style.css

body {
	font-family: "Trebuchet MS",Arial;
	font-size: 14px;
	background-color: #212426;
	color: #11151E;
}

input, textarea, select {
	font-family:inherit;
	font-size:inherit;
	font-weight:inherit;
}

#signup_form {
	margin-left: auto;
	margin-right: auto;
	width: 360px;

	font-size: 16px;

}

#signup_form .heading {
	text-align: center;
	font-size: 22px;
	font-weight: bold;
	color: #B9AA81;
}

#signup_form form {

	background-color: #B9AA81;
	padding: 10px;

	border-radius: 8px;
	-moz-border-radius: 8px;
	-webkit-border-radius: 8px;

}

#signup_form form label {
	font-weight: bold;
}

#signup_form form input[type=text],input[type=password] {
	width: 316px;
	font-weight: bold;
	padding: 8px;

	border: 1px solid #FFF;
	border-radius: 4px;
	-moz-border-radius: 4px;
	-webkit-border-radius: 4px;
}

#signup_form form input[type=submit] {
	display: block;
	margin: auto;
	width: 200px;
	font-size: 18px;
	background-color: #FFF;
	border: 1px solid #BBB;
}

#signup_form form input[type=submit]:hover {
	border-color: #000;
}

#signup_form .error {
	font-size: 13px;
	color: #690C07;
	font-style: italic;
}

This tutorial is not about CSS, so there is not much to explain here.

Edit: system/application/views/signup_form.php again.
Add the highlighted lines:




	
	Signup Form

As you can see, we just called the base_url() function, which returns http://localhost/ci_doctrine/ in this case. This function is part of the URL Helper.

Go to: http://localhost/ci_doctrine/signup, you will see:

Form Validation

If you press the submit button now, you will receive a 404 error:

Because our submit() method does not exist.

Edit: system/application/controllers/signup.php

load->helper(array('form','url'));
		$this->load->library('form_validation');
	}

	public function index() {
		$this->load->view('signup_form');
	}

	public function submit() {

		if ($this->_submit_validate() === FALSE) {
			$this->index();
			return;
		}

		$this->load->view('submit_success');

	}

	private function _submit_validate() {

		// validation rules
		$this->form_validation->set_rules('username', 'Username',
			'required|alpha_numeric|min_length[6]|max_length[12]');

		$this->form_validation->set_rules('password', 'Password',
			'required|min_length[6]|max_length[12]');

		$this->form_validation->set_rules('passconf', 'Confirm Password',
			'required|matches[password]');

		$this->form_validation->set_rules('email', 'E-mail',
			'required|valid_email');

		return $this->form_validation->run();

	}
}

Let's go over all the code we just added:

We add 2 methods: submit() and _submit_validate().
submit() get's called when the form is submitted to signup/submit.
First it validates the input. If it fails, it calls the index() method, which display the Signup Form again.
If no errors found, we load a View named submit_success, which we will create in a bit.
_submit_validate() is just a private function we created, that contains the form validation stuff.
And it returns the result of the Validation (true or false).

Let's look at how the form validation functions work:

When we loaded the Form_Validation Library earlier

First we set the rules like this:

$this->form_validation->set_rules('username', 'Username',
	'required|alpha_numeric|min_length[6]|max_length[12]');

The first parameter is the name of the form field.
The second parameter is the literal name for it, for display purposes.
The third parameter is a list of validation rules, separated by the pipe character "|".

You can see a list of validation rules here.

Finally we the run the validation by calling run() (line 42), which will return FALSE if a user input does not validate.

Displaying Validation Errors

Next thing we need to do is display the errors to the user.

Edit: system/application/views/signup_form.php




	
	Signup Form
	





	New User Signup

	

	',''); ?>

	
		Username: 
		
	
	
		Password: 
		
	
	
		Confirm Password: 
		
	
	
		E-mail:

validation_errors() displays a list of the errors returned from the form validation (line 17).

The first and second arguments we passed are the html codes to be used to enclose each error output.

Also, On lines 21 and 33 we now pass a second argument to the form_input() function call. This way, when the form is re-displayed to the user, it will be populated with the values he entered previously, so he doesn't have to start all over again.

Submit Success View

We will keep this one simple for now.

Create: system/application/views/submit_success.php

Success!

Test The Form

Enter some invalid data into the form and submit.

http://localhost/ci_doctrine/signup

And if you enter everything correctly, you should see the Success! message.

Saving the User

Now that our form works, we're going save the new user to the database using our Doctrine Model.

Edit the submit() function under system/application/controllers/signup.php:

_submit_validate() === FALSE) {
			$this->index();
			return;
		}

		$u = new User();
		$u->username = $this->input->post('username');
		$u->password = $this->input->post('password');
		$u->email = $this->input->post('email');
		$u->save();

		$this->load->view('submit_success');

	}

	// ...
}

As you can see, all we do is create a User object, assign the parameters, and call save(), and Doctrine should save the new record to the database. It's that simple.

Note: We are using $this->input->post() to get the submitted form values. When working with CodeIgniter, we do NOT use superglobals such as $_POST directly. This provides added security benefits.

Note2: We do NOT use any SQL filtering such as mysql_real_escape_string() when assigning the user input to the Doctrine Model, because Doctrine will take care of filtering for us.

Test the Form

Go to: http://localhost/ci_doctrine/signup, and submit it with proper values.
Check the contents of the table:

It's working great. But we're not quite done yet.

One Little Problem

Try submitting the form again with the same username and e-mail, and you will see:



Fatal error:  Uncaught exception 'Doctrine_Connection_Mysql_Exception' with message 'SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'testing' for key 'username'' in C:\wamp\www\ci_doctrine\system\application\plugins\doctrine\lib\Doctrine\Connection.php:1084
Stack trace:
#0 C:\wamp\www\ci_doctrine\system\application\plugins\doctrine\lib\Doctrine\Connection\Statement.php(253): Doctrine_Connection->rethrowException(Object(PDOException), Object(Doctrine_Connection_Statement))
#1 C:\wamp\www\ci_doctrine\system\application\plugins\doctrine\lib\Doctrine\Connection.php(1049): Doctrine_Connection_Statement->execute(Array)
#2 C:\wamp\www\ci_doctrine\system\application\plugins\doctrine\lib\Doctrine\Connection.php(693): Doctrine_Connection->exec('INSERT INTO use...', Array)
#3 C:\wamp\www\ci_doctrine\system\application\plugins\doctrine\lib\Doctrine\Connection\UnitOfWork.php(595): Doctrine_Connection->insert(Object(Doctrine_Table), Array)
#4 C:\wamp\www\ci_doctrine\system\application\plugins\doctrine\lib\Doctrine in C:\wamp\www\ci_doctrine\system\application\plugins\doctrine\lib\Doctrine\Connection.php on line 1084

The problem is, we tried to insert a duplicate value into a unique table column.

Handling Duplicates

We could simply check for the existence of a duplicate with something like this:

$user_table = Doctrine::getTable('User');
if ($user_table->findOneByUsername($username)) {
	// ... username already exists!
}

This is the first time we are looking into fetching records using Doctrine.

In the first line, we get the table object for our User Model. The name we pass is the name of the Model, and NOT the name of the table. This is important to know, in case your model and tables are named differently.

Then we call a magic function named findOneBy*(). It is magic, because it can be called on any other property, like findOneByEmail(). You basically need to append the property name, (which can be in camelCase format).

We could just add this code to our _submit_validate() function, for both username and email fields, however that's not quite what I want to do.

Extending CodeIgniter Libraries

Since we're using Doctrine to save time and avoid code duplication, it's only fitting that we continue with the same idea here.

We might need to check for duplicate records for other Models or from other Controllers later on. So we're going to build a reusable form validation rule, by extending the Form Validation class.

This way, other forms will have access to the same functionality later on, without having to duplicate code.

Create: system/application/libraries/MY_Form_validation.php

form_validation->set_message('unique',
			'The %s is already being used.');

		list($model, $field) = explode(".", $params, 2);

		$find = "findOneBy".$field;

		if (Doctrine::getTable($model)->$find($value)) {
			return false;
		} else {
			return true;
		}

	}
}

Let's go over the code:

Line 3: The new class needs to have the prefix MY_, and extends the core class named CI_Form_validation.
Line 5: We are going to create a validation rule named unique. With this form_validation class, names of the methods match the names of the rules, due to how the parent class is setup.
Line 5: First argument $value is value of the form field input.
Line 5: Second argument $params is the parameter passed to the rule. Our rule will have this structure: unique[model.field]. You will see it in a bit.
Lines 7-9: We need to get the CodeIgniter super object, so that we can access the form_validation instance, and set the error message.
Lines 12+: extract from the model.field values, build the name of the findOneBy function, and check for existing records.

You can read more about creating libraries in the docs.

Using the new form validation rule

Edit 2 lines in: system/application/controllers/signup.php

form_validation->set_rules('username', 'Username',
			'required|alpha_numeric|min_length[6]|max_length[12]|unique[User.username]');

		// ...

		$this->form_validation->set_rules('email', 'E-mail',
			'required|valid_email|unique[User.email]');

		// ...
	}
	// ...
}

As you can see, now we can use our new form validation rule named unique. We also provide the model name and the field name to this rule, in square brackets.

Test the form again

Go to: http://localhost/ci_doctrine/signup
Try to signup with the same values twice.

You will see 2 errors:

Stay Tuned

This is it for today. We covered quite a few new subjects and I hope you enjoyed it.

In the next episode, we create a User Login system.

See you next time!

"CodeIgniter and Doctrine from Scratch" Series:

CodeIgniter and Doctrine from scratch Day 2 – The Basics

Burak — Sat, 31 Oct 2009 01:42:44 +0000

In this episode:

- We do a quick fresh install of CodeIgniter and Doctrine, without going into details like last episode.
- Briefly go over some of the basic concepts of CodeIgniter and Doctrine.
- First we will review Controllers and Views in CodeIgniter.
- Then we will move on to Models using Doctrine. This is where things are going to get a little different, compared to other CodeIgniter tutorials out there.
- Finally we will preview a sample Doctrine Model and talk about what our main project is going to be.

"CodeIgniter and Doctrine from Scratch" Series:

Let’s get started and make sure we have a fresh CodeIgniter+Doctrine install ready for some code.

Fresh Quick CodeIgniter+Doctrine Install

Fresh Install Instructions:

(if you want to use your files from Day 1, skip to the next section instead)

Have your PHP+MySQL web server ready. Recommended: WAMP (for Mac: MAMP)
Download my CodeIgniter+Doctrine bundle (v1.0).
Extract and put the ci_doctrine folder into your web folder.
Create a database named ci_doctrine for our project.
Make sure your database info is correct in: system/application/config/database.php.
Make sure base_url is correct in: system/application/config/config.php.
See if its working: http://localhost/ci_doctrine/.

Done!

If you already have the files from Day 1:

(if you used the fresh install from the section above, skip this)

Rename or Copy your install folder to: ci_doctrine. (I decided to do this so we don’t keep changing our site url on every tutorial)
Delete: system/application/models/user.php
Delete: system/application/controllers/hello.php
Drop table: user
Edit: system/application/config/config.php

// in system/application/config/config.php
$config['base_url']	= "http://localhost/ci_doctrine/";

CodeIgniter URL structure

Url’s in CodeIgniter can look like these:

This url invokes the controller class named “CONTROLLER_NAME”, and call it’s method (function) named “METHOD_NAME”:


http://localhost/ci_doctrine/index.php/CONTROLLER_NAME/METHOD_NAME

Same as before, except it calls a method named index() by default:


http://localhost/ci_doctrine/index.php/CONTROLLER_NAME

Same as before. This time, it passes a “VALUE” as an argument to the controller method:


http://localhost/ci_doctrine/index.php/CONTROLLER_NAME/METHOD_NAME/VALUE

The value can be a number or a string.
You can keep appending more values in the url for passing additional arguments.

For More Info: Passing uri segments

CodeIgniter MVC (Model – View – Controller)

Models

We are going to be using Doctrine Model‘s, instead of CodeIgniter. I will explain it later in the tutorial.

If you still want to learn about CodeIgniter Models, read: CodeIgniter Models

Views

Views are created under system/application/views, and are named like my_view.php
They are the output templates. They can contain html, javascript and more.
Views also usually contain inline PHP code. (to display messages, run loops etc…)
Controllers typically load views for displaying output.

Official docs: CodeIgniter Views

Controllers

We already covered this in Day 1. Look for the section called “CodeIgniter Crash Course: Controllers”.

Controller and View together

Here is a sample View (system/application/views/my_view.php):

Some plain text.


	You can use HTML.



	Display variables passed from a controller: 

	 

	


You can even do loops: 

";

} ?>

Or in alternate syntax: 



	Counter shows:

Here is a sample Controller (system/application/controllers/sample_controller.php), that loads a view:

class Sample_controller extends Controller {

	function index() {
		$data = array();
		$data['message'] = "index was called";
		$data['another_message'] = "blah blah";

		$this->load->view('my_view',$data);
	}

}

Both of these url’s will work:


http://localhost/ci_doctrine/index.php/sample_controller/index

http://localhost/ci_doctrine/index.php/sample_controller

Browser would display:

Some plain text.
You can use HTML.
Display variables passed from a controller:
index was called
blah blah
You can even do loops:
Counter shows: 0
Counter shows: 1
Counter shows: 2
Or in alternate syntax:
Counter shows: 0
Counter shows: 1
Counter shows: 2

Note:

View contains a combination of raw output and simple inline PHP.
index() is the default Controller function, so we don’t have to put it in the url.
$this->load->view(‘my_view’,$data) loads the view and outputs it to the browser.
First argument ‘my_view’ is the name of the view file, without the .php part.
Second argument $data is an array, which passes variables to the view.
Example: $data['message'] becomes $message, and $data['another_message'] becomes $another_message, in our view.

(If you created the files above, to test the code, you can delete them now. We’re not going to use them again in our project.)

Doctrine Models

Models are classes that represent data (typically from your database).

For example, you might have a user table. So we can build a Model Class named “User” to represent the records in that table.

Our Model class should be able to peform CRUD (Create, Read, Update and Delete) operations. Luckily, Doctrine will be a great help in accomplishing this with minimal and clean code.

Differences in Usage (compared to CodeIgniter Models)

They extend the Doctrine_Record class (instead of the “Model” class).
They can be loaded like this: $u = new User(); (instead of this: $u = $this->load->model(‘user’);)
thanks to the Doctrine autoload we registered in our plugin.
It is not PHP4 compatible.

That is all you need to know for now. It should be an easy transition for those of you already working with CodeIgniter.

What does a Doctrine Model look like?

Here is a little PREVIEW of the kind of Model’s we are going to be building. We’ll get into more details in the next tutorials.

hasColumn('username', 'string', 255);
		$this->hasColumn('password', 'string', 255);
		$this->hasColumn('email', 'string', 255, array(
			'email' => true // It can validate e-mail input
		));

		// supports many column types, including enum
		$this->hasColumn('status', 'enum', null,
			array('values' => array('unverified', 'verified', 'disabled'))
		);

		$this->hasColumn('referer_id', 'integer', 4);
	}

	// setup some options
	public function setUp() {

		// creates a relationship with a model named Post
		$this->hasMany('Post as Posts', array(
			'local' => 'id',
			'foreign' => 'post_id'
		));

		// can even have a relationship with itself
		$this->hasOne('User as Referer', array(
			'local' => 'referer_id',
			'foreign' => 'id'
		));

		// causes 'created_at' and 'updated_at' fields to be updated automatically
		$this->actAs('Timestampable');

		// password field gets a mutator assigned, for automatic encryption
		$this->hasMutator('password', 'md5Password');

	}

	// a mutator function
	public function md5Password($value) {
		$this->_set('password', md5($value));
	}

}

Once we create Doctrine Model’s like this, we can do all kinds of database operations. Doctrine can even create the table based on the model information alone.

Also keep in mind that there are other ways of creating Doctrine Models, such as using schema files. But we will not get into that until later.

Stay Tuned

In the next episode, we will start building a project, which will be a Message Board and possibly more… This is a great candidate for a tutorial project with Doctrine because of all the different relationships involved between models such as: users, posts, threads, forums, groups, attachments etc…

See you next time!

"CodeIgniter and Doctrine from Scratch" Series:

PHP Method Chaining, plus Magic Setters (similar to jQuery)

Burak — Fri, 30 Oct 2009 15:30:22 +0000

Quick Disclaimer: Even if you know about PHP5 Method Chaining, don’t skip this article, because we will explore more than just that.

If you’re familiar with jQuery, you might know how it let’s you write short and clean code with the help of method chaining.

Not only will I show you how to accomplish this in PHP5, but I will also combine this feature with magic setter methods with the help of method overloading to make it even nicer.

It’s OK if you don’t know any of these terms. You should still be able to become familiarized with them by reading this article.

Defining Our Goal

Can you write an Email class that can do this?

set_from('test@email.com')
	->add_to('programming@gmail.com')
	->set_subject('Methods Chained')
	->set_body('Some long message')
	->send();

instead of this:

from = 'test@email.com';
$my_email->to []= 'programming@gmail.com';
$my_email->subject = 'Methods Chained';
$my_email->body = 'Some long message';
$my_email->send();

Your answer might be “Yes” if you’re already familiar with PHP Method Chaining.

But can you do it WITHOUT actually implementing the setter methods named “set_from()”, “add_to()” etc… in your class?

PHP Method Chaining in a Nutshell

For those of you not familiar with this term, here is what you need to know:

Method Chaining allows you to call multiple methods in a single line.

$my_object->foo()->bar()->taz()->etc();

All you need to do is return $this; at the end of your class methods.

class My_Class {

	public function foo() {
		// ... do something
		return $this;
	}

	public function bar() {
		// ... do something else
		return $this;
	}

}

Now your class methods can be called in a chain, resulting in a shorter (and hopefully cleaner) code.

Creating Our Magic Email Class

Before I explain more, I am just going to paste the entire class code here first:

Email.php

\n".
			"From: {$this->from} 
\n".
			"To: ".implode(',',$this->to)."
\n".
			"Subject: {$this->subject} 
\n".
			"Body: {$this->body} 
\n";

	}

	public function __call($name, $arguments) {

		if (substr($name,0,4) == 'set_') {
			$property = substr($name,4);
			$this->$property = $arguments[0];

		} else if (substr($name,0,4) == 'add_') {
			$property = substr($name,4);
			array_push($this->$property, $arguments[0]);
		}

		return $this;
	}
}

Please Note: I did NOT create any methods named set_from(), set_subject() or add_to() etc…, yet we’ll be able to call these setter methods with the help of some “magic”. Not to metion, we’ll be able to call them in a chain.

Now, let’s analyze the Code

The first part is simple enough. We’re just creating a new class:

class Email {

	public $from;
	public $to = array();
	public $subject;
	public $body;
// ...

Note that the $to property is going to be an array (we can e-mail multiple recipients). We’ll be adding values to it using “add_to()” method call.

Then we write a simple send() method to send our e-mail. (In this case, it’s just a fake one, for testing purposes)

// ...
	public function send() {

		// not actually sending e-mail
		// we're just testing our stuff

		echo "(not) Sending E-mail 
\n".
			"From: {$this->from} 
\n".
			"To: ".implode(',',$this->to)."
\n".
			"Subject: {$this->subject} 
\n".
			"Body: {$this->body} 
\n";

	}

Then we create the magic method named __call(). This method gets invoked when a non-existing function (e.g. set_from() or add_to()) has been called.

First argument $name is the name of the method called.
Second argument $arguments are the arguments passed to the method.

For more info: PHP Overloading Methods

// ...
	// this magic method gets called
	// when a non-existing method is called
	public function __call($name, $arguments) {

		// setting a property
		if (substr($name,0,4) == 'set_') {

			// get the property name we want to set
			$property = substr($name,4);
			// assign the value that was passed to this method
			// to the class property
			$this->$property = $arguments[0];

		// adding to an array property
		} else if (substr($name,0,4) == 'add_') {

			// get the property name we want to add to
			$property = substr($name,4);
			// add the value
			array_push($this->$property, $arguments[0]);

		}

		// for method chaining
		return $this;
	}
// ...

In the __call() function above, we do this:

If the method call was named set_*, we set the corresponding property value.
If the method call was named add_*, we add to the corresponding property an array value.
Finally, we return the class instance itself, which allows for method chaining.

Test The Code

If you test the following code:

set_from('test@email.com')
	->add_to('programming@gmail.com')
	->set_subject('Methods Chained')
	->set_body('Some long message')
	->send();

You should see this output:

(not) Sending E-mail
From: test@email.com
To: programming@gmail.com
Subject: Methods Chained
Body: Some long message

Thank you for reading

I hope you enjoyed this quick tutorial. If there are any other PHP concepts you would like to learn about, just leave a comment.

Thank you!

CodeIgniter and Doctrine from scratchDay 1 – Install and Setup

Burak — Wed, 28 Oct 2009 07:17:02 +0000

Being inspired by the wonderful series of articles/screencasts on the nettuts website called CodeIgniter From Scratch I decided to write my own series on using CodeIgniter and Doctrine together to build a functional website in a series of tutorials.

In this first part of series, I will show you how to create a basic CodeIgniter install and add Doctrine as a plug-in.

"CodeIgniter and Doctrine from Scratch" Series:

Why add Doctrine to CodeIgniter?

Before we get started, first let me explain the reason I am doing this. Doctrine is an Object Relational Mapper for PHP. It’s OK if you don’t know this term. It basically means that you can map your database tables to classes in your web application. And instances of these classes (i.e. objects) represent records in the database.

This makes it very easy to create, read, update and delete records from the database, while handling them almost like regular objects, so you don’t even have to write any queries. It will also handle relationships between your tables. There are several other benefits that I will not get into until later in these tutorials. See the Doctrine Introduction, if you would like more info right now.

Here is an illustration I put together, that might give you a visual picture.

First Step: Setup your development environment

If you already have a web server with PHP and MySQL setup, you can skip some of this.

Download and install WAMP (for Mac: MAMP)
Warning Skype Users: You must shutdown Skype first before you start up WAMP, due to a port conflict. After WAMP starts up, you can open Skype again.
Visit http://localhost/ in your browser to make sure it’s working
Open the “www” folder under the WAMP installation.
Create a folder named “ci_doctrine_day1″. We will put our files here.

Install CodeIgniter

Download CodeIgniter
Extract and copy the contents into your new “ci_doctrine_day1″ folder.
You may delete the “user_guide” folder.

Your new folders should look like this:

Go to http://localhost/ci_doctrine_day1

You should see this:

CodeIgniter Crash Course: Controllers

Controllers are called by CodeIgniter on every page load.
They are located under:

system/application/controllers/

The url structure looks like this:

http://localhost/ci_doctrine_day1/index.php/CONTROLLER_NAME/FUNCTION_NAME

For example if you open this url:

http://localhost/ci_doctrine_day1/index.php/hello/world

CodeIgniter will look for a controller class named “Hello” and call it’s method named “world()”.

So let’s create our first controller.

Our First Controller

Create this file: system/application/controllers/hello.php



Go to: http://localhost/ci_doctrine_day1/index.php/hello/world

You should see:
Hello CodeIgniter!
Please Note:

The class must extend Controller.
The class name must be capitalized.
The file name must be lowercase.

Recommended Reading:

http://codeigniter.com/user_guide/general/controllers.html

Install Doctrine
CodeIgniter allows us to add plug-ins. That’s how we will be installing it.

Create this folder: system/application/plugins
Create this folder: system/application/plugins/doctrine
Download Doctrine
Extract the files. Find the folder named “lib” and copy it to system/application/plugins/doctrine.

Now your folders should look like this:


Create the plug-in file: system/application/plugins/doctrine_pi.php

 $db_values) {

	// first we must convert to dsn format
	$dsn = $db[$connection_name]['dbdriver'] .
		'://' . $db[$connection_name]['username'] .
		':' . $db[$connection_name]['password'].
		'@' . $db[$connection_name]['hostname'] .
		'/' . $db[$connection_name]['database'];

	Doctrine_Manager::connection($dsn,$connection_name);
}

// CodeIgniter's Model class needs to be loaded
require_once BASEPATH.'/libraries/Model.php';

// telling Doctrine where our models are located
Doctrine::loadModels(APPPATH.'/models');

// (OPTIONAL) CONFIGURATION BELOW

// this will allow us to use "mutators"
Doctrine_Manager::getInstance()->setAttribute(
	Doctrine::ATTR_AUTO_ACCESSOR_OVERRIDE, true);

// this sets all table columns to notnull and unsigned (for ints) by default
Doctrine_Manager::getInstance()->setAttribute(
	Doctrine::ATTR_DEFAULT_COLUMN_OPTIONS,
	array('notnull' => true, 'unsigned' => true));

// set the default primary key to be named 'id', integer, 4 bytes
Doctrine_Manager::getInstance()->setAttribute(
	Doctrine::ATTR_DEFAULT_IDENTIFIER_OPTIONS,
	array('name' => 'id', 'type' => 'integer', 'length' => 4));

Read the comments in the code for explanations. However, don’t worry if you don’t understand all of it for now.
Database Setup and Configuration

Open phpMyAdmin: http://localhost/phpmyadmin/
Create a database named “ci_doctrine”



Edit file: system/application/config/database.php
Find the lines below and input the values.

// in system/application/config/database.php
// ... 

$db['default']['hostname'] = "localhost";
$db['default']['username'] = "root";
$db['default']['password'] = "";
$db['default']['database'] = "ci_doctrine";

// ...

We just edited the database configuration file of CodeIgniter.
More Configuration
Almost done.
config.php

Edit file: system/application/config/config.php

// in system/application/config/config.php
// ...

$config['base_url']	= "http://localhost/ci_doctrine_day1/";

// ...

Now CodeIgniter knows the url of our site.
autoload.php

Edit file: system/application/config/autoload.php

// in system/application/config/autoload.php
// ...

$autoload['plugin'] = array('doctrine');

// ...

This makes sure the Doctrine plug-in is always loaded.
Finished!
Now we’re ready to rock. Let’s start testing our setup.
Our First Doctrine Model
Create a user Table

Open phpMyAdmin: http://localhost/phpmyadmin/
Go to database “ci_doctrine”
Create a table named “user” with columns:

id => int, primary key, auto_increment,

username => varchar(255), unique,

password => varchar(255),

first_name => varchar(255),

last_name => varchar(255)

You may use this query:
CREATE TABLE `ci_doctrine`.`user` (
`id` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`username` VARCHAR( 255 ) NOT NULL ,
`password` VARCHAR( 255 ) NOT NULL ,
`first_name` VARCHAR( 255 ) NOT NULL ,
`last_name` VARCHAR( 255 ) NOT NULL ,
UNIQUE (
`username`
)
)


Create the Model

Create file: system/application/models/user.php

hasColumn('username', 'string', 255);
		$this->hasColumn('password', 'string', 255);
		$this->hasColumn('first_name', 'string', 255);
		$this->hasColumn('last_name', 'string', 255);
	}

}

Note:

We extend Doctrine_Record, instead of Model (which you normally would with CodeIgniter models).
Inside the function setTableDefinition() we need to define the table structure.
By default, Doctrine will look for a table with same name as the class. In this case: “user”. (this can be changed)
In our doctrine_pi.php file above in this tutorial, we specified for a default primary key named “id”. Therefore we don’t need to put it again in our User class.

Testing the Model: Add Some Users

Edit our controller we created earlier: system/application/controllers/hello.php

username = 'johndoe';
		$u->password = 'secret';
		$u->first_name = 'John';
		$u->last_name = 'Doe';
		$u->save();

		$u2 = new User;
		$u2->username = 'phprocks';
		$u2->password = 'mypass';
		$u2->first_name = 'Codeigniter';
		$u2->last_name = 'Doctrine';
		$u2->save();

		echo "added 2 users";
	}

}

We just generated 2 objects, and populated them with some data. Simply calling save() should save them into our database.
Note:

We are able to access the fields as parameters (e.g. $u->username), even though we did not create these as class parameters. Isn’t Doctrine nice?
If you are familiar with CodeIgniter, you might remember that you need to call $this->load->model() function to load models. However since we registered the autoload function of Doctrine, just saying “new User;” is enough.
We didn’t create the “save()” function, because it comes from the Doctrine_Record class we extended. It saves the objects to the database. There are many other functions and goodies that come with Doctrine classes, we will see later in the tutorials.


Open: http://localhost/ci_doctrine_day1/index.php/hello/user_test

You should see output:
added 2 users


Now go back to phpMyAdmin: http://localhost/phpmyadmin/
Browse the table ‘user’

Voila! Now you should be able see the 2 new records that just got created.

Stay Tuned
We just saw how to install and setup CodeIgniter with Doctrine. It took some work, but now we have a powerful MVC framework and ORM combination.
In the next tutorials, I will show you more practical examples and eventually build a functional website. You will see how easy it is to create models with Doctrine and save time from having to write repetitive CRUD (Create, read, update and delete) functions in all of your models. 
Doctrine will also help us handle the relationships between our classes, and let us avoid writing complex logic code and queries.
See you next time!

		

			"CodeIgniter and Doctrine from Scratch" Series:
			
				Day 1: Install and Setup
				Day 2: The Basics
				Day 3: User Signup Form
				Day 4: User Login
				Day 5: Database CRUD
				Day 6: Models with Relationships
				Day 7: Fixtures & Forum List
				Day 8: Hooks, Profiling & DQL
				Day 9: Templates & Data Hydrators
				Day 10: Pagination
				Day 11: Record Hooks
				Day 12: ...coming soon

CodeIgniter with Doctrine sample code [5 min. screencast]

Burak — Tue, 13 Oct 2009 21:54:49 +0000

In this video, I show some sample code I wrote in a fresh install of CodeIgniter and Doctrine. It’s very easy to use once you get familiar with it. This will allow you to avoid writing repetetive CRUD functionality in all of your CodeIgniter models.
Later I will post an article showing how to install Doctrine into your CodeIgniter setup.

In this video:

First I create 2 models.
Then I create the database tables based on these models.
Finally I insert some data into the tables by using very simple code that doesn’t involve any database queries.

GeoIP country lookup with PHP

Burak — Tue, 08 Sep 2009 23:22:32 +0000

How to get the surfers country using PHP? Most coders need to tackle this problem sooner or later. There are several options out there. There is even a package called GeoIP Location. However, since this does not come with most default installations, it may not be your best choice.

A company called Maxmind specializes in professional GeoIP solutions. However, when you dig through their website, you can find that they also provide some free databases and free code. I will show you how to use this free stuff in a portable way to easily and quickly add an Ip to Country lookup feature to your PHP script in 2 easy steps.

Step 1. Download database and PHP file

Download GeoLite Country (binary format), and extract the file GeoIP.dat.
Download geoip.inc.
Upload them to your server

Step 2. The Code

First, include the library and open the geoip database:

// include the php script
include("geoip.inc");

// open the geoip database
$gi = geoip_open("GeoIP.dat",GEOIP_STANDARD);

Getting the country code:

// to get country code
$country_code = geoip_country_code_by_addr($gi, $_SERVER['REMOTE_ADDR']);
echo "Your country code is: $country_code \n";

Getting the country name:

// to get country name
$country_name = geoip_country_name_by_addr($gi, $_SERVER['REMOTE_ADDR']);
echo "Your country name is: $country_name \n";

And finally, close the geoip database:

// close the database
geoip_close($gi);

This solution uses a very fast and compact binary file as the database, and it does not add any to load to your MySQL server. You can do thousands of lookups per second on very average hardware with this code.

PHP and Stuff

CodeIgniter and Doctrine from scratch. Day 11 – Record Hooks

"CodeIgniter and Doctrine from Scratch" Series:

Record Hooks

Forum Display Page Improvements

Adding a “First_Post” Relationship

Setting up the Hook

Rebuild the Database

Simplify Things

Testing the Results

Stay Tuned

"CodeIgniter and Doctrine from Scratch" Series:

CodeIgniter and Doctrine from scratch. Day 10 – Pagination

"CodeIgniter and Doctrine from Scratch" Series:

Upgrading Doctrine

One Small Fix

What is Pagination?

Pagination Links

Paginating Data

CodeIgniter Pagination Library

Adding More Data

Sorting By Last Post Date

( replies)

Pagination Links

The View

( replies)

The Model

The Controller

The Result

Stay Tuned

"CodeIgniter and Doctrine from Scratch" Series:

CodeIgniter and Doctrine from scratch. Day 9 – Templates & Data Hydrators

"CodeIgniter and Doctrine from Scratch" Series:

Templates

What and Why?

Creating a Template

CI+Doctrine Message Board

title; ?>

id, $forum->title) ?> (Threads[0]->num_threads; ?> threads)

Updating the Home Controller

See the Results

Data Hydrators (Doctrine)

HYDRATE_SCALAR

HYDRATE_ARRAY

Other Hydrators

Why?

CSS Changes

Forum Pages

Forums Controller

Forum View

( replies)

The Result

Stay Tuned

"CodeIgniter and Doctrine from Scratch" Series:

CodeIgniter and Doctrine from scratch. Day 8 – Hooks, Profiling & DQL

"CodeIgniter and Doctrine from Scratch" Series:

User Controls

Home View

CI+Doctrine Message Board

title; ?>

id, $forum->title) ?> (Threads->count(); ?> threads)

Testing

Profiling with Doctrine

Profiling the Home Page

CodeIgniter Hooks

Enabling Hooks

Creating a Profiler Hook

Adding the Hooks

Testing

Optimizing with DQL

Reducing the Number of Queries

Getting Count

One More Change

id, $forum->title) ?> (Threads[0]->num_threads; ?> threads)

Profile Again

Conclusions

Stay Tuned

"CodeIgniter and Doctrine from Scratch" Series:

Top 20+ MySQL Best Practices

CodeIgniter and Doctrine from scratch Day 7 – Fixtures & Forum List