So let’s wrap up the framework tutorial by doing something a little dynamic to highlight the power of a framework.

class ArticleController extends CController
{

   public function actionView()
   {
      $article = Article::model()->findByAttributes(array(
         ‘title’=>$_REQUEST[‘name’]));
      $this->render(‘viewFile’, array(‘model’=>$article));
   }
}

So what could we possibly be doing here? We’re dynamically finding a specific article and rendering it to the view. The idea is this code is made to render 1 of many articles in your blog, not just the same about us paragraph. In technical terms, we’re finding an article in the database, and passing its corresponding object that Yii generates to the view.

The view file would look like this:

<h1><?php echo $model->title; ?></h1>

<div>

   <?php echo $model->body; ?>

</div>

The view file here is passed the entire $model object, rather than just a plain variable that holds a single variable (i.e. previously the about us paragraph). This object has properties for the article title and the body of its article.

So the next question you should ask yourself is: ok so how does the blog know which blog article to display? The answer is simple: through clues in the URL you provide.

In this case, the URL will be something like this:  yoursite.com/article/view/name/the-article-name.

Let’s break down this url:

/article = the controller to use

/view = the controller’s action to use

/name = the key in the “global” PHP array called $_REQUEST

/the-article-name = name of the article.

So basically PHP has a global array called $_REQUEST that you can use anywhere in your code (in any scope) which stores values in the URL. In standard php, urls would be structured like this:

yoursite.com/article/view?name=the-article-name.

However, in order to provide more beautiful URLs the Yii framework is programmed to give you access to that same data by structuring your urls using standard file path notation, i.e. /name/the-article-name.

Then in the php code you can simply access $_REQUEST[‘name’] to get the value “the-article-name”;

Finally, this line:

Article::model()->findByAttributes(array(‘title’=>$_REQUEST[‘name’]));

loops up an article in the article database table that has the title stored in $_REQUEST[‘name’].

So this allows your blog site to have URLs leading to different articles like this:

yoursite.com/article/view/name/article-1.

yoursite.com/article/view/name/article-2 

yoursite.com/article/view/name/article-3.

Final note: you may be wondering why the title is hyphenated. In reality, your article table would have a column called “url” or “slug” which is basically the hyphenated version of the article title. You could also have URLs like this:

yoursite.com/article/view/id/1

yoursite.com/article/view/id/2

yoursite.com/article/view/id/3

And then your finder code would look up the article in the database by its unique ID number column like so:

Article::model()->findByPk(array(‘id=>$_REQUEST[‘id’]));

Note: the findByPk() method standards for Find by Primary Key, which usually is a numerical auto-incrementing unique ID #.

The crux of what’s going on here is that the provided information in the URL can be different. Therefore your application code needs to behave dynamically and know how to deal with different provided information. This is basically the cornerstone of dynamic programming. It’s what makes coding in languages like PHP so different than the static HTML language, which is just basic commands about the placement/style of elements on a web page. In short, the code you write needs to be able to deal with various possibilities and still produce a result. Your code is expecting different “input” so it can give you varied, aka “dynamic” output.

The true true cornerstone here is this variable $_REQUEST[‘name’], which can hold different values. It’s one of the many ways your application can receive varied input.

So, fueled with a database of articles (and their urls/slugs), you have a ton of data to run searches on via Yii’s various model finder methods, i.e. Article::model()->findByPk(). I’ll explain what’s going on in that exact bit of code in a second, but first I’d like to finish my point here: the point is that with all the data in your database you’re innately prepared to deal with all sorts of input, such as the article ID # provided in the requested URL. You can then basically make a comparison and see if any data in your database has a matching ID #, and get the corresponding database row. From there it’s simple: yii turns it into a model object, and you can access the various columns in that row.

So back to this line:

Article::model()->findByPk()

All that is there is a common yii code structure to look up articles in the article table by primary key. You have to start with Article::model()-> . Why it starts with that is beyond the scope of this article, but the basic point is that your Article class has these tools available to it, and because of its tableName() method which you previously saw that returns the text string “article”, knows to look for rows in the article table by their ID #. Yii has a great deal of tools to perform complex database lookups. This is the easiest example.

That concludes the introduction to frameworks set of tutorials. You’re now armed with a basic understanding of the goals that MVC frameworks accomplish. You should start imagining how your application will work to dynamically display different content based on varying input. Keep in mind there are other places users can provide input: cookies (i.e. data your site stores for a long period of time in your visitors’ web browser), data submitted via forms, etc. Cookies, forms, URLs are really the main 3. They may actually be the only 3. But that won’t stop you from building wonderful complex and innovative applications. That’s all you need. After this initial input, a whole signal flow process can ensue in your application where one bit of code functions as input to another block of code, and then that block of code’s output is the input to yet another block of code. For example, if the user’s user ID was stored in a cookie, with every request you could lookup in your user table within your database the row corresponding to the current visitor, and then put that visitor’s name on every page. So the idea is you originally had a user ID as input from a cookie, and that served as input to a database lookup in the User table, and then that output served as input to a function that combines the first and last name to create a complete name, which then was output to the browser. That’s a chain or flow of continuous input and ouput, and you can do as much as you want in that chain, and it can go on for as long as you want. The result will always be the same though: you pass the result as an HTML web page to the browser from your server.