Project Issues

Welcome to name); ?> user->isGuest):?>

You last logged in on user->lastLoginTime ); ?>.

And as we are in there, let's go ahead and remove all of the other autogenerated help text, which is everything below these lines we just added. Once you save your changes and log in again, you should see something similar to the screenshot below, which displays the welcome message following by a formatted time indicating your last successful login: Iteration 4: User Management and Authentication [ 170 ] Summary This iteration was the first of two iterations focused on user management, authentication and authorization. We created the ability to manage CRUD operations for application users, making many adjustments to the new user creation process along the way. We added a new base class for all of our Active Record classes, so that we can easily manage our audit history table columns that are present on all of our tables. We also updated our code to properly manage the user's last login time, which we are storing in the database. In doing so, we learned about tapping into the CActiveRecord validation workflow to allow for pre and post-validation processing. We then focused on understanding the Yii authentication model in order to enhance it to meet our application's requirements: that the user credentials be validated against the values stored in the database. Now that we have covered authentication, we can turn focus to second part of Yii's auth-and-auth framework, authorization. This will be the focus of the next iteration. Iteration 5: User Access Control User based web applications, like our TrackStar application, typically need to control access to certain functionality based on who is making the request. When we speak of user access control, we are referring, at a high-level, to some questions the application needs to ask when requests are being made such as: • Who is making the request? • Does that user have the appropriate permission to access the requested functionality? The answers to these questions help the application respond appropriately. The work completed in the last iteration provides the application with the ability to answer the first question. Our implementation of basic user management extended the application user authentication process to use the database. The application now allows users to establish their own authentication credentials and validates the username and password against the database stored values upon user login. After a successful login, the application now knows exactly who is making subsequent requests. This iteration is going to focus on helping the application answer the second question. Once the user has provided appropriate identification, the application needs a way to determine if they also have the permission to perform the requested action. We'll extend our basic authorization model by taking advantage of Yii's user access control features. Yii provides both a simple access control filter as well as a more sophisticated role-based access control (RBAC) implementation as means to help us address our user authorization requirements. We'll be taking a closer look at both of these as we work to implement the user access requirements for the TrackStar application. Iteration 5: User Access Control [ 172 ] Iteration planning When we first introduced our TrackStar application back in Chapter 3, The TrackStar Application, we mentioned that the application has two high-level user types: anonymous and authenticated. This is simply making a distinction between a user that has successfully logged in, and one who has not. We have also introduced the idea of authenticated users having different roles within a project. We established that, within a project, a user can be in one of three roles: • A project owner (is granted all administrative access to the project) • A project member (is granted more limited access to project features and functionality) • A project reader (only has access to read the content associated with a project, not change it in any way) The focus of this iteration is to implement an approach to managing the access control granted to application users. We need a way to create and manage our roles and permissions, assign them to users, and enforce the access control rules we want for each user role. In order to achieve this goal, we need to identify all the more granular items we will work on within this iteration. The following is a list of these items: • Implement a strategy to force the user to log in before gaining access to any project or issue related functionality • Create user roles and associate those roles with a specific functionality permission structure • Implement the ability to assign users to roles (and their associated permissions) • Ensure our role and permission structure exists on a per project basis (that is, allow users to have different permissions within different projects) • Implement the ability to associate users to projects and, at the same time, to roles within that project • Implement the necessary authorization access checking throughout the application to appropriately grant or deny access to the application user based on their permissions Luckily, Yii comes with a lot of built-in functionality to help us implement these requirements. So, let's get started. Chapter 8 [ 173 ] Running our existing test suite As always, we should kick things off by running all of our existing unit tests to ensure that the tests pass: % cd WebRoot/protected/tests/ % phpunit unit/ PHPUnit 3.4.12 by Sebastian Bergmann. ................ Time: 3 seconds OK (10 tests, 27 assertions) Everything looks good, so we can start making changes. accessControl filter We introduced filters back in Chapter 6, Iteration 3: Adding Tasks when we added one to help us verify the project context when dealing with our Issue related CRUD operations. The Yii Framework provides a filter called accessControl. This filter can be directly used in controller classes to provide an authorization scheme to verify whether or not a user can access a specific controller action. In fact, the astute reader will remember that when we were implementing our filterProjectContext filter back in Chapter 6, we noticed that access control filter was already included in the filters list for both our IssueController and ProjectController classes, as follows: /** * @return array action filters */ public function filters() { return array( 'accessControl', // perform access control for CRUD operations ); } This was included in the autogenerated code produced by using the Gii code generator to create our skeleton CRUD operations on the Issue and Project AR classes. Iteration 5: User Access Control [ 174 ] The default implementation is set up to allow anyone to view a list of existing issues and projects. However, it restricts access of creating and updating to authenticated users, and further restricts the Delete action to a special admin user. You might remember that when we first implemented CRUD operations on projects, we had to log in before we were able to create new ones. The same was true when dealing with issues and again with users. The mechanism controlling this authorization and access is exactly this accessControl filter. Let's take a closer look at this implementation within the ProjectController.php class file. There are two methods relevant to access control in this file, ProjectController::filters() and ProjectController::accessRules(). The code for the first method is listed as follows: /** * @return array action filters */ public function filters() { return array( 'accessControl', // perform access control for CRUD operations ); } The following code is used for the second method: /** * Specifies the access control rules. * This method is used by the 'accessControl' filter. * @return array access control rules */ public function accessRules() { return array( array('allow', // allow all users to perform 'index' and 'view' actions 'actions'=>array('index','view'), 'users'=>array('*'), ), array('allow', // allow authenticated user to perform 'create' and 'update' actions 'actions'=>array('create','update'), 'users'=>array('@'), ), array('allow', // allow admin user to perform 'admin' and 'delete' actions Chapter 8 [ 175 ] 'actions'=>array('admin','delete'), 'users'=>array('admin'), ), array('deny', // deny all users 'users'=>array('*'), ), ); } The filters() method is already familiar to us. It is where we specify all the filters to be used in the controller class. In this case, we have only one, accessControl, which refers to a filter provided by the Yii Framework. This filter uses the other method, accessRules(), which defines the rules that drive the access restrictions. In the accessRules() method mentioned previously, there are four rules specified. Each rule is represented as an array. The first element of the array is either allow or deny. These indicate the granting or denying of access respectively. The rest of the array consists of name=>value pairs specifying the remaining parameters of the rule. Let's look at the first rule defined previously: array('allow', // allow all users to perform 'index' and 'view' actions 'actions'=>array('index','view'), 'users'=>array('*'), ), This rule allows the index and view controller actions to be executed by any user. The asterisk '*' special character is a way to specify any user (anonymous, authenticated, or otherwise). The second rule is as follows: array('allow', // allow authenticated user to perform 'create' and 'update' actions 'actions'=>array('create','update'), 'users'=>array('@'), ), It allows for any authenticated user to access the create and update controller actions. The '@' special character is a way to specify any authenticated user. Iteration 5: User Access Control [ 176 ] The third rule is as follows: array('allow', // allow admin user to perform 'admin' and 'delete' actions 'actions'=>array('admin','delete'), 'users'=>array('admin'), ), This specifies that a specific user, named admin, is allowed to access the actionAdmin() and actionDelete() controller actions. The fourth rule is as follows: array('deny', // deny all users 'users'=>array('*'), ), It denies access to all controller actions to all users. Access rules can be defined using a number of context parameters. The previously mentioned rules define actions and users to create the rule context, but there are several others listed as follows: • Controllers: This rule specifies an array of controller IDs to which the rule should apply. • Roles: This rule specifies a list of authorization items (roles, operation, permissions) to which the rule applies. This makes used of the RBAC feature we will be discussing in the next section. • Ips: This rule specifies a list of client IP addresses to which this rule applies. • Verbs: This rule specifies which HTTP request types (GET, POST, and so on) apply to this rule. • Expression: This rule specifies a PHP expression whose value indicates whether or not the rule should be applied. • Actions: This rule specifies the action method, by use of the corresponding action ID, to which the rule should match. • Users: This rule specifies the users to which the rule should apply. The current application user's name attribute is used for matching. Three special characters can also be used here: °° *: any user °° ?: anonymous users °° @: authenticated users Chapter 8 [ 177 ] The access rules are evaluated one by one in the order by which they are specified. The first rule that matches the current pattern determines the authorization result. If this rule is an allow rule, the action can be executed; if it is a deny rule, the action cannot be executed; if none of the rules matches the context, the action can still be executed. It is for this reason that the fourth rule is stipulated. If we did not stipulate a rule that denied all actions to all users at the end of our rules list, then we would not achieve our desired access restrictions. As an example, take the second rule. It specifies that authenticated users are allowed access to the create and update actions. However, it does not stipulate that anonymous users be denied access. It says nothing about anonymous users. The fourth rule ensures that all other requests that do not match one of the first three specific rules be denied access. With this already in place, altering our application to deny anonymous users access to all project, issue, and user related functionality is a snap. All we have to do is change the special character '*' of the users array value to the '@' special character. This will only allow authenticated users to access the actionIndex() and actionView() controller actions. All other actions are already restricted to authenticated users. Let's make this change in all of our controllers. Open up all three of the following files: ProjectController.php, IssueController.php, and UserController.php files and alter the first rule in the access control rules to be: array('allow', // allow only authenticated users to perform 'index' and 'view' actions 'actions'=>array('index','view'), 'users'=>array('@'), ), After making these changes, the application will require a login prior to accessing any of our project, issue, or user functionality. We still allow anonymous user access to the SiteController class action methods, which we kept because this is where our login actions are located. We have to be able to access the login page if we are not already logged in. Iteration 5: User Access Control [ 178 ] Role-based access control Now that we have used the simple accessControl filter as a broad stroke to limiting access to authenticated users, we need to turn focus to meeting some more granular access control needs of our application. As we mentioned, users will play certain roles within a project. The project will have users of type owner, who can be thought of as project administrators. They will be granted all access to manipulate the project. The project will also have users of type member, who will be granted some access to project functionality, but a subset of what owners are able to perform. Finally, the project can have users of type reader, who are only able to view project related content and not alter it in any way. To achieve this type of access model based on the role of a user, we turn to the RBAC feature of Yii. RBAC is an established approach in computer systems security to managing the access permissions of authenticated users. In short, the RBAC approach defines roles within an application. Permissions to perform certain operations are also defined and then associated with roles. Users are then assigned to a role and through the role association, acquire the permissions defined for that role. There is plenty of documentation available for curious readers about the general RBAC concept and approach. One good source of information is Wikipedia: http://en.wikipedia. org/wiki/Role-based_access_control. We'll focus on the specifics of Yii's implementation of RBAC. Yii's implementation of RBAC is simple, elegant, and powerful. At the foundation of RBAC in Yii is the idea of the authorization item. The authorization item is simply a permission to do things in the application. These permissions can be categorized as roles, tasks, or operations, and, as such, form a permission hierarchy. Roles can consist of tasks (or other roles), tasks can consist of operations (or other tasks) and operations are the most granular permission level. For example, in our TrackStar application, we need a role of type owner. So, we would create an authorization item of type role with the name owner. This role could then consist of tasks such as a "user management" and "issue management". These tasks could then further consist of the atomic operations that make up these tasks. For example, the user management task could consist of the operations create new user, edit user, and delete user. This hierarchy allows for inheritance of these permissions so that, given this example, if a user is assigned to the owner role, they inherit the permission to perform create, edit, and delete user operations. Chapter 8 [ 179 ] Typically in RBAC, you assign a user to one or more roles and the user inherits the permissions that have been assigned to those roles. This holds true for RBAC in Yii as well. However, in this model, we can associate users to any authorization item, not just ones of type role. This allows us the flexibility to associate a permission to a user at any level of granularity. If we only want to grant the delete user operation to a specific user, and not give them all the access that an owner role would have, we can simply associate the user to this atomic operation. This makes RBAC in Yii very flexible. Configuring the authorization manager Before we can establish an authorization hierarchy, assign users to roles, and perform access permission checking, we need to configure the authorization manager application component, authManager. This component is responsible for storing the permission data and managing the relationships between permissions as well as providing the methods to check whether or not a user does have access to perform a particular operation. Yii provides two types of authorization managers: CPhpAuthManager and CDbAuthManager. CPhpAuthManager uses a PHP script file to store the authorization data. CDbAuthManager, as you might have guessed, stores the authorization data in a database. The authManager is configured as an application component. Configuring the authorization manager consists simply of specifying which of these two types to use and then setting its initial class property values. As we are already using a database in the TrackStar application, it makes sense for us to make use of the CDbAuthManager implementation. To make this configuration, open up the main config file, protected/config/main.php, and add the following to the application components array: 'authManager'=>array( 'class'=>'CDbAuthManager', 'connectionID'=>'db', ), This establishes a new application component named authManager, specifies the class type to be CDbAuthManager, and sets the connectionID class property to be our database connection component. Now we can access this anywhere in our application using Yii::app()->authManager. Iteration 5: User Access Control [ 180 ] Creating the RBAC database tables As mentioned, the CDbAuthManager class uses database tables to store the permission data. It expects a specific schema. That schema is identified in the framework file YiiRoot/framework/web/auth/schema.sql. It is a simple, yet elegant, schema consisting of three tables, AuthItem, AuthItemChild, and AuthAssignment. The AuthItem table holds the information defining the authorization item, that is the role, task or operation. The AuthItemChild table houses the parent/child relationships that form our hierarchy of authorization items. Finally, the AuthAssignment table is an association table that holds the association between a user and an authorization item. The basic DDL statements for the tables are the following: create table AuthItem ( name varchar(64) not null, type integer not null, description text, bizrule text, data text, primary key (name) ); create table AuthItemChild ( parent varchar(64) not null, child varchar(64) not null, primary key (parent,child), foreign key (parent) references AuthItem (name) on delete cascade on update cascade, foreign key (child) references AuthItem (name) on delete cascade on update cascade ); create table AuthAssignment ( itemname varchar(64) not null, userid varchar(64) not null, bizrule text, data text, primary key (itemname,userid), foreign key (itemname) references AuthItem (name) on delete cascade on update cascade ); Chapter 8 [ 181 ] This schema is taken directly from the Yii Framework file /framework/ web/auth/schema.sql and does not exactly adhere to our table naming conventions that we use for our other tables. These are the default table names expected by CDbAuthManager class. However, you can configure this class to use different table names. For simplicity, we use the schema exactly as defined in the framework. Creating the RBAC authorization hierarchy After adding the previously mentioned tables to our _dev and _test databases, we need to populate them with our roles and permissions. We will do this using the API provided by the authManager. To keep things simple, we are going to only define roles and basic operations. We will not set up any formal RBAC tasks for now. The following figure displays the basic hierarchy we wish to define: Iteration 5: User Access Control [ 182 ] The diagram shows inheritance from the top down. So, Owners have all the permissions listed, plus they inherit all the permissions from both the Member and Reader roles. Likewise, member inherits permissions from the Reader. What we now need to do is establish this permission hierarchy in the application. As previously mentioned, the best way to do this is to write code to utilize the authManager API. As an example, the following code creates a new role and a new operation and then adds the relationship between the role and the permission: $auth=Yii::app()->authManager; $role=$auth->createRole('owner'); $auth->createOperation('createProject','create a new project'); $role->addChild('createProject'); In the preceding code, we first get an instance of the authManager. We then use its createRole(), createOperation(), and addChild() API methods to create a new owner role, and a new operation named createProject. We then add the permission to the owner role. This only demonstrates the creation of a small part of our needed hierarchy, all of the remaining relationships we outlined in the previous figure need to be created in a similar manner. To accomplish the building of our needed permission hierarchy, we are going to write a simple shell command, which is to be executed at the command line. This will extend the command options of the yiic command-line tool we used to create our initial application. Writing a console application command We introduced the yiic command-line tool back in Chapter 2, when we created a new HelloWorld! application, and again in Chapter 4 when we used it to initially create the structure of our TrackStar Web application. The yiic tool is a console application in Yii that executes tasks in the form of commands. We have used the webapp command to create a new applications, and back in Chapter 2, we also used the yiic shell command to create a new controller class. We have been using the newer Gii code generator tool when initially creating our model classes and our CRUD scaffolding code. However, there are commands available with the yiic tool for creating these as well. As a reminder, the yiic shell command allows you to interact with a web application on the command line. You can execute it from the folder that contains the entry script for the application. Then, within the context of the specific application, it provides tools to automatically generate new controllers, views and data models. Chapter 8 [ 183 ] Console applications in Yii are easily extended by writing custom commands, and this is exactly what we are going to do. We are going to extend the yiic shell command tool set by writing a new command-line tool to allow us to build our RBAC authorization hierarchy in a consistent and repeatable manner. Writing a new command for a console application is quite simple. It is simply a class that extends from CConsoleCommand which, at a minimum, implements the needed run() method that will be executed when the command is called. The name of the class should be exactly the same as the desired command name, followed by Command. In our case, our command will simply be rbac, so we'll name our class RbacCommand. Lastly, in order to make this command available to the yiic console application, we need to save our class into the /protected/commands/shell/ folder. So, create a new file called RbacCommand.php, and add the following PHP code: _authManager=Yii::app()->authManager)===null) { Iteration 5: User Access Control [ 184 ] echo "Error: an authorization manager, named 'authManager' must be configured to use this command.\n"; echo "If you already added 'authManager' component in application configuration,\n"; echo "please quit and re-enter the yiic shell.\n"; return; } //provide the oportunity for the use to abort the request echo "This command will create three roles: Owner, Member, and Reader and the following premissions:\n"; echo "create, read, update and delete user\n"; echo "create, read, update and delete project\n"; echo "create, read, update and delete issue\n"; echo "Would you like to continue? [Yes|No] "; //check the input from the user and continue if they indicated yes to the above question if(!strncasecmp(trim(fgets(STDIN)),'y',1)) { //first we need to remove all operations, roles, child relationship and assignments $this->_authManager->clearAll(); //create the lowest level operations for users $this->_authManager->createOperation("createUser","create a new user"); $this->_authManager->createOperation("readUser","read user profile information"); $this->_authManager->createOperation("updateUser","update a users information"); $this->_authManager->createOperation("deleteUser","remove a user from a project"); //create the lowest level operations for projects $this->_authManager->createOperation("createProject","cre ate a new project"); $this->_authManager->createOperation("readProject","read project information"); $this->_authManager->createOperation("updateProject","up date project information"); $this->_authManager->createOperation("deleteProject","del ete a project"); //create the lowest level operations for issues Chapter 8 [ 185 ] $this->_authManager->createOperation("createIssue","crea te a new issue"); $this->_authManager->createOperation("readIssue","read issue information"); $this->_authManager->createOperation("updateIssue","upda te issue information"); $this->_authManager->createOperation("deleteIssue","dele te an issue from a project"); //create the reader role and add the appropriate permissions as children to this role $role=$this->_authManager->createRole("reader"); $role->addChild("readUser"); $role->addChild("readProject"); $role->addChild("readIssue"); //create the member role, and add the appropriate permissions, as well as the reader role itself, as children $role=$this->_authManager->createRole("member"); $role->addChild("reader"); $role->addChild("createIssue"); $role->addChild("updateIssue"); $role->addChild("deleteIssue"); //create the owner role, and add the appropriate permissions, as well as both the reader and member roles as children $role=$this->_authManager->createRole("owner"); $role->addChild("reader"); $role->addChild("member"); $role->addChild("createUser"); $role->addChild("updateUser"); $role->addChild("deleteUser"); $role->addChild("createProject"); $role->addChild("updateProject"); $role->addChild("deleteProject"); //provide a message indicating success echo "Authorization hierarchy successfully generated."; } } } Iteration 5: User Access Control [ 186 ] The comments in the previous code should help tell the story of what is happening here. We provide a simple getHelp() method so that our new command can be quickly understood by other users. This is also consistent with the other commands offered by yiic. All of the real action happens in the run() method. It ensures the application has a vaild authManager application component defined. It then allows the user to have a last chance to cancel the request before proceeding. If the user of this command indicates they want to continue, it will proceed to clear all previously entered data in the RBAC tables and then create a new authorization hierarchy. The hierarchy that is created here is exactly the one we discussed previously. We can see that, even based on our fairly simple hierarchy, there is still a significant amount of code needed. Typically, one would need to develop a more intuitive UI wrapped around these authorization manager APIs to provide an easy interface to manage roles, tasks, and operations. For the purposes of our TrackStar application, we can simply set up the needed database tables, execute this logic once to establish the initial relationships, and then hope we don't have to make too many changes to it. This is a great solution for establishing a quick RBAC permission structure, but not ideal for the long-term maintenance of a permission structure that might change significantly. In a real-world application, you will most likely need a different, more interactive tool to help maintain the RBAC relationships. The Yii extension library (http://www.yiiframework.com/ extensions/) provides some packaged solutions for this. Let's try out this new command. Navigate to the root of your application and execute the shell command (Remember YiiRoot stands for where you have installed the Yii Framework): % YiiRoot/framework/yiic shell Yii Interactive Tool v1.1 (based on Yii v1.1.2) Please type 'help' for help. Type 'exit' to quit. >> Now type help to see a list of available commands: >> help At the prompt, you may enter a PHP statement or one of the following commands: - controller - crud - form - help Chapter 8 [ 187 ] - model - module - rbac Type 'help ' for details about a command. We see that our rbac command has now been added to the list. Let's attempt to learn more by typing help rbac: >> help rbac USAGE rbac DESCRIPTION This command generates an initial RBAC authorization hierarchy. This is exactly what we wrote in the getHelp() method of our command class. You can certainly be more verbose, and add more detail as desired. Now let's run the command to establish the required hierarchy: >> rbac This command will create three roles: Owner, Member, and Reader and the following premissions: create, read, update and delete user create, read, update and delete project create, read, update and delete issue Would you like to continue? [Yes|No] Yes Authorization hierarchy successfully generated. Then go ahead and exit the shell: >> exit Assuming you typed Yes when prompted to continue, all of the authorization hierarchy was created. Iteration 5: User Access Control [ 188 ] As you may recall, we have setup a separate database to run our tests against, namely trackstar_test. As we will need this authorization hierarchy in our test database as well, we need to run the yiic shell command under the context of the TrackStar application pointed to the test database. As our test database connection string is defined in our test config file, /protected/config/test.php, we need to bootstrap the yiic shell with this config file rather than main.php. This is easy to do, as the yiic shell command allows you to explicitly specify a config file to load. So, let's once again start the yiic shell, but let's specify our test configuration when starting up so that the interactive web application shell is configured to use our test database: % YiiRoot/framework/yiic shell protected/config/test.php Yii Interactive Tool v1.1 (based on Yii v1.1.2) Please type 'help' for help. Type 'exit' to quit. >> rbac This command will create three roles: Owner, Member, and Reader and the following premissions: create, read, update and delete user create, read, update and delete project create, read, update and delete issue Would you like to continue? [Yes|No] Yes Authorization hierarchy successfully generated. >> exit Now we have our RBAC authorization hierarchy available in our test database as well. Assigning users to roles Everything we have done thus far does establish an authorization hierarchy, but it does not yet assign permissions to users. We accomplish this by assigning users to one of the three roles we created: owner, member, or reader. For example, if we wanted to associate the user whose unique user ID is 1 with the member role, we would execute the following: $auth=Yii::app()->authManager; $auth->assign('member',1); Chapter 8 [ 189 ] Once these relationships are established, checking a user's access permission is a simple matter. We simply ask the application user component whether or not the current user has the permission. For example, if we wanted to check whether or not the current user is allowed to create a new issue, we could do so with the following syntax: If( Yii::app()->user->checkAccess('createIssue')) { //perform needed logic } In this example, we assigned user ID 1 to the role of member, and as in our authorization hierarchy the member role inherits the createIssue permission, the previously mentioned if statement would evaluate to true, assuming we were logged in to the application as user 1. We will be adding this authorization assignment logic as part of the business logic executed when adding a new member to a project. We'll be adding a new form that allows us to add users to projects, and the ability to choose a role as part of the process. But first we need to address one other aspect of how user roles need to be implemented within this application, namely that they need to apply on a per project basis. Adding RBAC roles to projects We now have a basic RBAC authorization model in place, but these relationships apply to the application as a whole. Our needs for the TrackStar application are slightly more complex. We need to define roles within the context of projects, not just globally across the application. We need to allow users to be in different roles, depending on the project. For example, a user may be in the reader role of one project, a member of a second project, and an owner of some third project. Users can be associated with many projects, and the role they are assigned needs to be specific to the project. Iteration 5: User Access Control [ 190 ] The RBAC framework in Yii does not have anything built-in that we can take advantage of to meet this requirement. The RBAC model is only intended to establish relationships between roles and permissions. It does not know (nor should it) anything about our TrackStar projects. In order to achieve this extra dimension to our authorization hierarchy, we will create a separate database table to maintain the relationship between a user, a role and a project. The DDL statement for this table is as follows: create table tbl_project_user_role ( project_id INTEGER NOT NULL, user_id INTEGER NOT NULL, role VARCHAR(64) NOT NULL, primary key (projectId,userId,role), foreign key (project_id) references tbl_project (id), foreign key (user_id) references tbl_user (id), foreign key (role) references AuthItem (name) ); So, open your favorite database editor and ensure this table is part of both the main and test database models. Adding RBAC business rules Although the previous database table will hold the basic information to answer the question as to whether a user is assigned to a role within the context of a particular project, we still need our RBAC authorization hierarchy to answer questions concerning whether or not a user has permission to perform certain functionality. Although the RBAC model in Yii does not know about our TrackStar projects, it does have a very powerful feature that we can take advantage of. When you create authorization items or assign an item to a user, you can associate a snippet of PHP code that will be executed during the Yii::app()->user->checkAccess() call. When defined, this bit of code must return true before the user would be granted that permission. One example of the usefulness of this feature is in the context of applications that allow users to maintain personal profile information. Often in this case, the application would like to ensure that a user have the permission to update only their own profile information and no one else's. In this case we could create an authorization item called updateProfile, and then associate a business rule that checks if the current user's ID is the same as the user ID associated with the profile information. Chapter 8 [ 191 ] In our case, we are going to associate a business rule with the role assignment. When we assign a user to a specific role, we will also associate a business rule that will check the relationship within the context of the project. The checkAccess() method also allows us to pass in an array of additional parameters for the business rule to use to perform its logic. We'll use this to pass in the current project context so that the business rule can call a method on the Project AR class to determine whether or not the user is assigned to that role within that project. The business rule we'll create will be slightly different for each role assignment. For example, the one we'll use when assigning a user to the owner role will look like the following: $bizRule='return isset($params["project"]) && $params["project"]- >isUserInRole('owner');'; The ones for member and reader will be the similar. We will also have to pass in the project context when we call the checkAccess() method. So now when checking if a user has access to, for example, the createIssue operation, the code would look like: $params=array('project'=>$project); if(Yii::app()->user->checkAccess('createIssue',$params)) { //proceed with issue creation logic } Here, the $project variable is the Project AR class instance associated with the current project context (remember that almost all functionality in our application occurs within the context of a project). Implementing the new Project AR methods Now that we have added a new database table to house the relationship between user, role and project, we need to implement the required logic to manage and verify the data in this table. We will be adding public methods to the Project AR class to handle adding and removing data from this table, as well as verifying the existence of rows. As you may have guessed, we will start by writing a test. Iteration 5: User Access Control [ 192 ] First, let's add the ability to create a new association between a user, project and role. Open up the unit test file protected/tests/unit/ProjectTest.php, and add the following test: public function testUserRoleAssignment() { $project = $this->projects('project1'); $this->assertEquals(1,$project->associateUserToRole()); } and then run the following test: % cd /Webroot/protected/tests/ % phpunit unit/ProjectTest.php PHPUnit 3.4.12 by Sebastian Bergmann. .....E Time: 0 seconds There was 1 error: 1) ProjectTest::testUserRoleAssignment CException: Project does not have a method named "associateUserToRole". … FAILURES! Tests: 6, Assertions: 13, Errors: 1. We have our test failing, and for obvious reasons. We need to add the public method to the Project AR class that will take in a role name and a user ID and create the association between role, user and project. Open up the protected/models/ Project.php file and add the following method with just enough logic to get the test to pass: /** * creates an association between the project, the user and the user's role within the project */ public function associateUserToRole() { return 1; } Chapter 8 [ 193 ] Running the test again will result in success, as we have simply returned exactly what test is looking to compare: % phpunit unit/ProjectTest.php PHPUnit 3.4.12 by Sebastian Bergmann. ...... Time: 0 seconds OK (6 tests, 14 assertions) Now let's alter the test to pass in the role name and the user ID to the method on the project class: public function testUserRoleAssignment() { $project = $this->projects('project1'); $user = $this->users('user1'); $this->assertEquals(1,$project->associateUserToRole('owner', $user->id)); } Then alter the Project::associateUserToRole() method to take in these parameters, and actually insert a row into our tbl_project_user_role table: public function associateUserToRole($role, $userId) { $sql = "INSERT INTO tbl_project_user_role (project_id, user_id, role) VALUES (:projectId, :userId, :role)"; $command = Yii::app()->db->createCommand($sql); $command->bindValue(":projectId", $this->id, PDO::PARAM_INT); $command->bindValue(":userId", $userId, PDO::PARAM_INT); $command->bindValue(":role", $role, PDO::PARAM_STR); return $command->execute; } Here we are using the Yii Framework CDbCommand class to execute an SQL statement against the database. An instance of CDbCommand is what is returned from calling the createCommand() method on our database connection. We are also using binding our parameter values using the bindValue() method on the CDbCommand. This is a good practice which can reduce the risk of SQL injection attacks as well as help improve the performance of SQL statements that are executed multiple times. Iteration 5: User Access Control [ 194 ] The CDbCommand::execute() method used previously returns the number of rows affected by the executed SQL insert statement. A successful insert will affect one row, so the integer value 1, will be returned. The test compares the return value of this execution to the integer 1. If you are following along, you should verify that the test does pass. However, if you run it a second time, it will fail with a database integrity constraint violation, as it will be trying to insert the same Primary key again. We should take a moment to address this issue. As we are dealing with a database table in our tests, we should really add a fixture for this table to be able to run our tests in a repeatable and consistent manner. Add a new file called tbl_project_user_role.php to the fixtures folder, protected/tests/fixtures/, and have it simply return a blank array: 'Project', 'users'=>'User', 'projUsrAssign'=>':tbl_project_user_assignment', 'projUserRole'=>':tbl_project_user_role', ); Even though we did not add any explicit fixture data to our fixture, the fixture manager will truncate our tbl_project_user_role table, thereby removing all previously inserted rows before each test. We can now run our tests multiple times without incurring any database constraint errors. When we change a user's role within a project, or remove a user from a project, we will need to remove this association. So, let's also add a method to do that. We can keep working with the same test method. Let's alter our test and add a call to remove the association, just after we add it: public function testUserRoleAssignment() { $project = $this->projects('project1'); $user = $this->users('user1'); $this->assertEquals(1,$project->associateUserToRole('owner', $user->id)); $this->assertEquals(1,$project->removeUserFromRole('owner', $user->id)); } Chapter 8 [ 195 ] Run the test again and, of course, it will fail. We need to implement this new method on the Project AR class. Add the following method at the bottom of that class: /** * removes an association between the project, the user and the user's role within the project */ public function removeUserFromRole($role, $userId) { $sql = "DELETE FROM tbl_project_user_role WHERE project_ id=:projectId AND user_id=:userId AND role=:role"; $command = Yii::app()->db->createCommand($sql); $command->bindValue(":projectId", $this->id, PDO::PARAM_INT); $command->bindValue(":userId", $userId, PDO::PARAM_INT); $command->bindValue(":role", $role, PDO::PARAM_STR); return $command->execute(); } This simply deletes the row from the table that houses the association between the role, user and the project. It will return the number of rows affected, which, if it successfully deleted a row, should be 1. So far, our test adds a new association and then removes it. We should run it again to make sure everything passes: % phpunit unit/ProjectTest.php PHPUnit 3.4.12 by Sebastian Bergmann. ...... Time: 1 second OK (6 tests, 15 assertions) We now have implemented the methods for adding and removing our associations. We now need to add functionality to determine whether or not a given user is associated with a role within the project. We will also add this as a public method to our Project AR class. So, starting with a test, add the following test method to ProjectTest.php: public function testIsInRole() { $project = $this->projects('project1'); $this->assertTrue($project->isUserInRole('member')); } Iteration 5: User Access Control [ 196 ] This is designed to test the implementation of the Project::isUserInRole() method. As we have not implemented this method yet, our test will certainly fail. Let's ensure it does: % phpunit unit/ProjectTest.php PHPUnit 3.4.12 by Sebastian Bergmann. ......E Time: 0 seconds There was 1 error: 1) ProjectTest::testIsInRole CException: Project does not have a method named "isUserInRole". … FAILURES! Tests: 7, Assertions: 15, Errors: 1. To get it to pass, add the following method to the bottom of the Project AR model class: /** * @return boolean whether or not the current user is in the specified role within the context of this project */ public function isUserInRole($role) { return true; } This should be enough to get our test to pass: % phpunit unit/ProjectTest.php … OK (7 tests, 16 assertions) Chapter 8 [ 197 ] Now we need to implement the appropriate logic to see if an association exists. Alter the method in the Project AR class to be: public function isUserInRole($role) { $sql = "SELECT role FROM tbl_project_user_role WHERE project_ id=:projectId AND user_id=:userId AND role=:role"; $command = Yii::app()->db->createCommand($sql); $command->bindValue(":projectId", $this->id, PDO::PARAM_INT); $command->bindValue(":userId", Yii::app()->user->getId(), PDO::PARAM_INT); $command->bindValue(":role", $role, PDO::PARAM_STR); return $command->execute()==1 ? true : false; } This again executes the SQL directly to select from our table. It expects an input role name and uses the current application user, defined by Yii::app()->user, to make up the primary key it is searching for. Run the test again: % phpunit unit/ProjectTest.php … Time: 1 second, Memory: 14.25Mb There was 1 failure: 1) ProjectTest::testIsInRole Failed asserting that is true. … FAILURES! Tests: 7, Assertions: 16, Failures: 1. Our test is failing again. The test is failing because the isUserInRole() method is using Yii::app()->user->getId() to get the current user ID, and this is returning nothing. Our test did not explicitly set the current user prior to making this call. Let's add the needed logic to properly set the current user's user ID. Alter the test method to be: public function testIsInRole() { $user = $this->users('user1'); Yii::app()->user->setId($user->id); $project = $this->projects('project1'); $this->assertTrue($project->isUserInRole('member')); } Iteration 5: User Access Control [ 198 ] This sets the current user ID to that of user1 from our users fixture data. Now run the test again: % phpunit unit/ProjectTest.php … Time: 1 second, Memory: 14.25Mb There was 1 failure: 1) ProjectTest::testIsInRole Failed asserting that is true. … FAILURES! Tests: 7, Assertions: 16, Failures: 1. Our test is still failing, but now it is failing because the row does not exist in the table, the user ID of user1 is not associated with the owner role for this project. So, let's create that association before we call the isUserInRole() method. We could use the other methods we added and tested earlier to create and remove these associations in order to establish the relationship. However, in an attempt to keep this test as isolated as possible from other tests or Project AR methods, we'll lean on fixture data to provide the initial conditions. When we first added the fixture file tests/fixtures/tbl_project_user_role. php, we had it simply return an empty array. Let's change that to have it populate a row with a project ID of 2, a user ID of 2, and a role name of member: return array( 'row1'=>array( 'project_id' => 2, 'user_id' => 2, 'role' => 'member', ), ); As our previous tests for the adding and removing of associations are using user1 and project1 fixture data, we've played it safe to avoid any conflicts by using different IDs to seed this data. Chapter 8 [ 199 ] Now we'll use this fixture data to set our application user ID as well as to create the Project AR class. Alter the test method to be: public function testIsInRole() { $row1 = $this->projUserRole['row1']; Yii::app()->user->setId($row1['user_id']); $project=Project::model()->findByPk($row1['project_id']); $this->assertTrue($project->isUserInRole('member')); } Here we are using the fixture data defined at the top of the class, called projUserRole, to retrieve our seeded row data. We then use this data to set the user ID, and create the Project AR instance by calling Project::model()->findByPk. We then test to ensure the user has, indeed, been associated with the member role. Now if we run our test: % phpunit unit/ProjectTest.php … OK (7 tests, 16 assertions) Our test is passing once again. We have written and tested the methods to add and remove our role associations within a project, and the method to determine whether or not a given user is associated with a project role. We are going to write one final test. We are going to write a test for our end-to-end implementation of how we plan to add this extra project dimension to Yii's RBAC structure. We talked about achieving this by adding a business rule to the Yii RBAC auth assignment whenever we associate a user to a role. Let's write one final method in to test this approach. Open back up the ProjectTest.php unit test file, and add the following test method: public function testUserAccessBasedOnProjectRole() { $row1 = $this->projUserRole['row1']; Yii::app()->user->setId($row1['user_id']); $project=Project::model()->findByPk($row1['project_id']); $auth = Yii::app()->authManager; $bizRule='return isset($params["project"]) && $params["project"]->isUserInRole("member");'; $auth->assign('member',$row1['user_id'], $bizRule); $params=array('project'=>$project); $this->assertTrue(Yii::app()->user->checkAccess('updateIssue' ,$params)); Iteration 5: User Access Control [ 200 ] $this->assertTrue(Yii::app()->user->checkAccess('readIssue',$ params)); $this->assertFalse(Yii::app()->user->checkAccess('updateProje ct',$params)); } This final test method uses other existing, and already tested, API methods to achieve the test, so there is no need to go through our normal TDD steps. In some ways it could be argued that this is more of a functional test than a unit test, but we think it still belongs in this unit test class. We will take the same approach (as we did with the previous test) to setup our user ID, and establish the project AR instance by using the data from the tbl_project_ user_role.php fixture file. We then create an instance of the auth manager class that we use to establish the assignment of the user to the role owner. However, before we make that assignment, we create the business rule. The business rule uses the $params array by first checking the existence of a project element in the array, and then calls the isUserInRole() method on the Project AR class, which it assumes is the value of that array element. We explicitly pass in the name, owner, to this method, as that is the role we are going to be assigning. Finally, we make the call to the Yii RBAC related method Yii::app()->user->checkAccess() to see if the current user, who has now been assigned to the role owner in our RBAC auth hierarchy as well as is associated with this role within the project. We are checking whether or not the user has the permission to update an issue, which we know anyone in the member role should have. We expect this to return true. We are also making a couple of other assertions to test (and demonstrate) the permission inheritance. We expect a user in the member role to inherit permissions from reader. So we also test that the user has access to the readIssue permission, which we know is a child of the reader role in our auth hierarchy. Finally, we should expect to be denied access to operations exclusive to the owner role. So we test to ensure false is returned when we check access to the updateProject operation. Running the tests again: % phpunit unit/ProjectTest.php … OK (8 tests, 19 assertions) All the project tests are passing. It seems as if this approach will do the trick. Chapter 8 [ 201 ] As we are explicitly using the code: $auth->assign('member',$row1['user_id'], $bizRule); to insert a row in the AuthAssignment table, we will get a database integrity violation if we attempt to run this test again. Basically, it will be try to re-insert the same row, and this will violate a data integrity constraint we have defined on this table. To avoid this, we need to allow the fixture manager to also manage this table. We have seen this before. Simply add a new file to the fixtures folder protected/ tests/fixtures/AuthAssignment.php, and have it return an empty array. Then, alter the fixtures array defined at the top of the ProjectTest.php file to include this in the fixtures definition: public $fixtures=array( 'projects'=>'Project', 'users'=>'User', 'projUsrAssign'=>':tbl_project_user_assignment', 'projUserRole'=>':tbl_project_user_role', 'authAssign'=>':AuthAssignment', ); Now our AuthAssignment table will be reset to a consistent state before each test is run. Before we leave this test, let's add a little more to ensure that if we pass in a project to which the user is not assigned, they have no access. As we explicitly set up the association to be with project id #2, let's just check the user's access using project id #1. Add the following at the end of the testUserAccessBasedOnProjectRole() method: //now ensure the user does not have any access to a project they are not associated with $project=Project::model()->findByPk(1); $params=array('project'=>$project); $this->assertFalse(Yii::app()->user->checkAccess('updateIssue',$p arams)); $this->assertFalse(Yii::app()->user->checkAccess('readIssue',$par ams)); $this->assertFalse(Yii::app()->user->checkAccess('updateProject', $params)); Here we are creating a new project instance based on project_id = 1. We know the user is not associated with this project at all, so all of the checkAccess() calls should return false. Iteration 5: User Access Control [ 202 ] Adding Users To Projects In the previous iteration, we added the ability to create new users of the application. However, we do not yet have a way to assign users to specific projects, and further, assign them to roles within these projects. Now that we have our RBAC approach in place, we need to build out this new functionality. The implementation of this needed functionality involves several coding changes. However, we have provided similar examples of the types of changes needed, and have covered all of the related concepts when implementing functionality from previous iterations. Consequently, we will move pretty quickly through this, and pause only briefly to highlight just a few things we have not yet seen. At this point, the reader should be able to make all of these changes without much help, and is encouraged to do so as a hands-on exercise. To further encourage this exercise, we'll first list everything we are going to do fulfill this new feature requirement. You can then close the book and try some of these out yourself before looking further down at our implementation. To achieve this goal we will perform the following: • Using a test-first approach, add a public static method called getUserRoleOptions() to the Project model class that returns a valid list of role options using the auth manager's getRoles() method. We will use this to populate a roles selection drop-down field in the form for adding a new user to a project. • Using a test-first approach, add a new public method called associateUserToProject($user) to the Project model class to associate a user to a project. This can insert directly into the tbl_project_use_ assignment table to make an association between the user and the project. • Using a test-first approach, add a new public method called isUserInProject($user) to the Project model class to determine if a user is already associated with a project. We will use this in our validation rules upon form submission so that we don't attempt to add a duplicate user to a project. • Add a new form model class called ProjectUserForm, extending from CFormModel for a new input form model. Add to this form model class three attributes: $username, $role, and $project. Also add validation rules to ensure that both the username and the role are required input fields and that the username should further be validated through a custom verify() class method. This verify() method should: °° Attempt to create a new User AR class instance by finding a user by matching the input username. Chapter 8 [ 203 ] °° If the attempt was successful, it should continue to associate the user to a project using the new method, associateUserToProject($user), added previously as well as associate the user to the role in the RBAC approach discussed earlier in this chapter. If no user was found matching the username, it needs to set and return an error. (If needed, review the LoginForm::authenticate() method as an example of a custom validation rule method.) • Add a new view file under views/project called adduser.php to display our new form for adding users to projects. This form only needs two input fields: username and role, which is a dropdown choice listing. • Add a new controller action method called actionAdduser() to the ProjectController class, and alter its accessRules() method to ensure it is accessible by authenticated members. This new action method is responsible for rendering the new view to display the form and handling the post back when the form is submitted. Again, we encourage the reader to attempt these changes on their own first. We list our code changes in the following sections. Altering the Project model class To the Project class, we added three new public methods, one of them static so it can be called without the need for a specific instance: /** * Returns an array of available roles in which a user can be placed when being added to a project */ public static function getUserRoleOptions() { return CHtml::listData(Yii::app()->authManager->getRoles(), 'name', 'name'); } /** * Makes an association between a user and a the project */ public function associateUserToProject($user) { $sql = "INSERT INTO tbl_project_user_assignment (project_id, user_id) VALUES (:projectId, :userId)"; $command = Yii::app()->db->createCommand($sql); Iteration 5: User Access Control [ 204 ] $command->bindValue(":projectId", $this->id, PDO::PARAM_INT); $command->bindValue(":userId", $user->id, PDO::PARAM_INT); return $command->execute(); } /* * Determines whether or not a user is already part of a project */ public function isUserInProject($user) { $sql = "SELECT user_id FROM tbl_project_user_assignment WHERE project_id=:projectId AND user_id=:userId"; $command = Yii::app()->db->createCommand($sql); $command->bindValue(":projectId", $this->id, PDO::PARAM_INT); $command->bindValue(":userId", $user->id, PDO::PARAM_INT); return $command->execute()==1 ? true : false; } There is nothing special to further describe in the preceding code. As these were all public methods on the Project model class, we ended up with the following two test methods within the ProjectTest unit test class: public function testGetUserRoleOptions() { $options = Project::getUserRoleOptions(); $this->assertEquals(count($options),3); $this->assertTrue(isset($options['reader'])); $this->assertTrue(isset($options['member'])); $this->assertTrue(isset($options['owner'])); } public function testUserProjectAssignment() { //since our fixture data already has the two users assigned to project 1, we'll assign user 1 to project 2 $this->projects('project2')->associateUserToProject($this- >users('user1')); $this->assertTrue($this->projects('project1')- >isUserInProject($this->users('user1'))); } Chapter 8 [ 205 ] Adding the new form model class Just as was used in the approach for the login form, we are going to create a new form model class as a central place to house our form input parameters and to centralize the validation. This is a fairly simple class that extends from the Yii class CFormModel and has attributes that map to our form input fields, as well as one to hold the valid project context. We need the project context to be able to add users to projects. The entire class is listed as follows: 'User'), array('username', 'verify'), ); } /** * Authenticates the existence of the user in the system. * If valid, it will also make the association between the user, role and project * This is the 'verify' validator as declared in rules(). */ public function verify($attribute,$params) { if(!$this->hasErrors()) // we only want to authenticate when no other input errors are present { $user = User::model()->findByAttributes(array('username'=> $this->username)); if($this->project->isUserInProject($user)) { $this->addError('username','This user has already been added to the project.'); } else { $this->project->associateUserToProject($user); $this->project->associateUserToRole($this->role, $user->id); $auth = Yii::app()->authManager; $bizRule='return isset($params["project"]) && $params["project"]->isUserInRole("'.$this->role.'");'; $auth->assign($this->role,$user->id, $bizRule); } } } } Chapter 8 [ 207 ] Adding the new action method to the project controller We need a controller action to handle the initial request to display the form for adding a new user to a project. We placed this in the ProjectController class and named it actionAdduser(). The code for this is as follows: public function actionAdduser() { $form=new ProjectUserForm; $project = $this->loadModel(); // collect user input data if(isset($_POST['ProjectUserForm'])) { $form->attributes=$_POST['ProjectUserForm']; $form->project = $project; // validate user input and set a sucessfull flassh message if valid if($form->validate()) { Yii::app()->user->setFlash('success',$form->username . " has been added to the project." ); $form=new ProjectUserForm; } } // display the add user form $users = User::model()->findAll(); $usernames=array(); foreach($users as $user) { $usernames[]=$user->username; } $form->project = $project; $this->render('adduser',array('model'=>$form, 'usernames'=>$usernames)); } Iteration 5: User Access Control [ 208 ] This is all pretty familiar to us at this point. It handles both the initial GET request to display the form as well as the POST request after the form is submitted. It follows very much the same approach as our actionLogin() method in our site controller. The preceding highlighted code is, however, something we have not seen before. If the submitted form request is successful, it sets what is called a flash message. A flash message is a temporary message stored briefly in the session. It is only available in the current and the next requests. Here we are using the setFlash() method of our CWebUser application user component to store a temporary message that the request was successful. When we talk about the view next, we will see how to access this message, and display it to the user. Also, in the previous code, we created an array of available usernames from the system. We will use this array to populate the data of one of Yii's UI widgets, CAutoComplete, which we will use for the username input form element. As its name suggests, as we type in the input form field, it will provide choice suggestions based on the elements in this array. One other change we had to make to the ProjectController class, was to add in this new action method to the basic access rules list so that a logged in user is allowed to access this action: public function accessRules() { return array( array('allow', // allow all users to perform 'index' and 'view' actions 'actions'=>array('index','view', 'adduser'), 'users'=>array('@'), ), … Adding the new view file to display the form Our new action method is calling ->render('adduser') to render a view file, so we need to get that created. A full listing of our implementation for protected/views/ project/adduser.php is as follows: pageTitle=Yii::app()->name . ' - Add User To Project'; $this->breadcrumbs=array( $model->project->name=>array('view','id'=>$model->project->id), 'Add User', ); Chapter 8 [ 209 ] $this->menu=array( array('label'=>'Back To Project', 'url'=>array('view','id'=>$model->project->id)), ); ?>

Add User To project->name; ?>

user->hasFlash('success')):?>

user->getFlash('success'); ?>

beginWidget('CActiveForm'); ?>

Fields with * are required.

labelEx($model,'username'); ?> widget('CAutoComplete', array( 'model'=>$model, 'attribute'=>'username', 'data'=>$usernames, 'multiple'=>false, 'htmlOptions'=>array('size'=>25), )); ?> error($model,'username'); ?>

labelEx($model,'role'); ?> dropDownList($model,'role', Project::getUserRoleOptions()); ?> error($model,'role'); ?>

endWidget(); ?>

Iteration 5: User Access Control [ 210 ] Most of this we have seen before. We are defining active labels and active form elements that tie directly to our ProjectUserForm form model class. We populate our dropdown using the static method we implemented earlier on the project model class. We also added a simple link to the menu op to take us back to the project details page. The highlighted code above is new to us. This is an example of using the flash message that we introduced and used in the actionAdduser() method. We access the message we set using setFlash() by asking the same user component if it has a flash message, using hasFlash('succcess'). We feed the hasFlash() method the exact name we gave it when we set the message. This is a nice way to present the user with some simple feedback about their previous request. One other small change we made as to add a simple link from the project details page so we could access this form form the application. The following line was added to the project show.php view file's list of link options: [$m odel->projectId)); ?>] This gives us access to the new form. Putting it all together With all of these changes in place, we can navigate to our new form by viewing one of the project details pages. For example, viewing project id #1 through the URL: http://localhost/trackstar/index.php?r=project/view&id=1. In the right column menu of operations is a hyperlink Add User To Project and clicking on that link should display the following page: Chapter 8 [ 211 ] You can use the forms we have previously built to create new projects and users to ensure you have a few added to the application. Then you can play around with adding users to projects. As you type in the Username field, you will see suggestions for auto-completion. If you attempt to add a user that is not in the user database table, you should see an error telling you so. If you attempt to enter a user that has already been added to the project, you will see an error message. On successful additions, you will see a short flash message indicating success. Checking authorization level The last thing we need to do in this iteration is to add the authorization checks for the different functionality that we have implemented. Earlier in this chapter we outlined and then implemented the RBAC authorization hierarchy for the different roles we have. Everything is in place to allow or deny access to functionality based on the permissions that have been granted to users within projects, with one exception. We have not yet implemented the necessary access checking when attempting to request functionality. The application is still using the simple access filter that is defined on each of our project, issue and user controllers. We'll do this for one of our permissions and then leave the remaining implementation as an exercise for the reader. We can notice from looking back at our authorization hierarchy that only project owners should be able to add new users to a project. So, let's start with that. What we will do is not even display the link on the project details page unless the current user is in the owner role for that project (you might want to make sure you have added at least one owner and one member or reader to a project so you can test it when complete). Open up the protected/views/project/view.php view file where we placed the link on the menu items for adding a new user. Remove that array element from the menu array items, and then push it on the end of the array only if the checkAccess() method returns true. The following code shows how the menu items should be defined: $this->menu=array( array('label'=>'List Project', 'url'=>array('index')), array('label'=>'Create Project', 'url'=>array('create')), array('label'=>'Update Project', 'url'=>array('update', 'id'=>$model->id)), array('label'=>'Delete Project', 'url'=>'#', 'linkOptions'=>array ('submit'=>array('delete','id'=>$model->id),'confirm'=>'Are you sure you want to delete this item?')), array('label'=>'Manage Project', 'url'=>array('admin')), array('label'=>'Create Issue', 'url'=>array('issue/create', 'pid'=>$model->id)), Iteration 5: User Access Control [ 212 ] ); if(Yii::app()->user->checkAccess('createUser',array('project'=>$mod el))) { $this->menu[] = array('label'=>'Add User To Project', 'url'=>array('adduser', 'id'=>$model->id)); } This implements the same approach we had discussed earlier in the chapter. We call checkAccess() on the current user, and send in the name of the permission we want to check. Also, as our roles are within the context of projects, we send in the project model instance as an array input. This will allow the business rule to execute what has been defined in the authorization assignment. Now if we log in as a project owner for a particular project and navigate to that project details page, we'll see the menu option for adding a new user to the project. Conversely, if you log in in as a user in the member or reader role of that same project, and again navigate to the details page, this link will not display. This, of course, will not prevent a savvy user from gaining access to this functionality by navigating using the URL directly. For example, even while logged in to the application as a user in the reader role for, say, project id #2, if I navigate directly to the URL: http://hostname/tasctrak/index.php?r=project/adduser&id=2 I can still access the form. To prevent this, we need to add our access check directly to the action method itself. So, in the actionAdduser() method in the project controller class, we can add the check: public function actionAdduser() { $project = $this->loadModel(); if(!Yii::app()->user->checkAccess('createUser', array('project'=>$project))) { throw new CHttpException(403,'You are not authorized to per-form this action.'); } $form=new ProjectUserForm; // collect user input data … Now when we attempt to access this URL directly, we will be denied access unless we in the project owner role for the project. We won't go through implementing the access checks for all of the other functionality. Each would be implemented in a similar manner. Chapter 8 [ 213 ] Summary We have covered a lot in this iteration. First we were introduced to the basic access control filter that Yii provides as one method to allow and deny access to specific controller action methods. We used this approach to ensure that users be logged into that application before gaining access to any of the main functionality. We then took a detailed walk through Yii's RBAC model which allows for much more sophisticated approach to access control. We built an entire user authorization hierarchy based on application roles. In the process, we were introduced to writing console applications in Yii, and to some of the benefits of this wonderful feature. We then built in new functionality to allow the addition of users to projects and being able to assign them to appropriate roles within those projects. Finally, we discovered how to implement the needed access checks throughout the application to utilize the RBAC hierarchy to appropriately grant/deny access to feature functionality. Iteration 6: Adding User Comments With the implementation of user management in the past two iterations, our Trackstar application is really starting to take shape. The bulk of our primary application feature functionality is now behind us. We can now start to focus on some of the nice-to-have features. The first of these features that we will tackle is the ability for users to leave comments on project issues. The ability for users to engage in a dialogue about project issues is an important part of what any issue tracking tool should provide. One way to achieve this is to allow users to leave comments directly on the issues. The comments will form a conversation about the issue and provide an immediate, as well as historical context to help track the full lifespan of any issue. We will also use comments to demonstrate using Yii widgets and establishing a portlet model for delivering content to the user (for more information on Portlets, visit http://en.wikipedia.org/wiki/Portlet). Iteration planning The goal of this iteration is to implement feature functionality in the Trackstar application to allow users to leave and read comments on issues. When a user is viewing the details of any project issue, they should be able to read all comments previously added as well as create a new comment on the issue. We also want to add a small fragment of content, or portlet, to the project-listing page that displays a list of recent comments left on all of the issues. This will be a nice way to provide a window into recent user activity and allow easy access to the latest issues that have active conversations. Iteration 6: Adding User Comments [ 216 ] The following is a list of high-level tasks that we will need to complete in order to achieve these goals: • Design and create a new database table to support comments • Create the Yii AR class associated with our new comments table • Add a form directly to the issue details page to allow users to submit comments • Display a list of all comments associated with an issue directly on the issues details page • Take advantage of Yii widgets to display a list of the most recent comments on the projects listing page Creating the model As always, we should run our existing test suite at the start of our iteration to ensure all of our previously written tests are still passing as expected. By this time, you should be familiar with how to do that, so we will leave it to the reader to ensure that all the unit tests are passing before proceeding. We first need to create a new table to house our comments. Below is the basic DDL definition for the table that we will be using: CREATE TABLE tbl_comment ( `id` INTEGER NOT NULL PRIMARY KEY AUTO_INCREMENT, `content` TEXT NOT NULL, `issue_id` INTEGER, `create_time` DATETIME, `create_user_id` INTEGER, `update_time` DATETIME, `update_user_id` INTEGER ) As each comment belongs to a specific issue, identified by the issue_id, and is written by a specific user, indicated by the create_user_id identifier, we also need to define the following foreign key relationships: ALTER TABLE `tbl_comment` ADD CONSTRAINT `FK_comment_issue` FOREIGN KEY (`issue_id`) REFERENCES `tbl_issue` (`id`); ALTER TABLE `tbl_comment` ADD CONSTRAINT `FK_comment_author` FOREIGN KEY (`create_user_id`) REFERENCES `tbl_user` (`id`); Chapter 9 [ 217 ] If you are following along, please ensure this table is created in both the trackstar_dev and trackstar_test databases. Once a database table is in place, creating the associated AR class is a snap. We have seen this many times in previous iterations. We know exactly how to do this. We simply use the Gii code creation tool's Model Generator command and create an AR class called Comment. If needed, refer back to Chapters 5 and 6 for all the details on using this tool to create model classes. Since we have already created the model class for issues, we will need to explicitly add the relations to to the Issue model class for comments. We will also add a relationship as a statistical query to easily retrieve the number of comments associated with a given issue (just as we did in the Project AR class for issues). Alter the Issue::relations() method as such: public function relations() { return array( 'requester' => array(self::BELONGS_TO, 'User', 'requester_id'), 'owner' => array(self::BELONGS_TO, 'User', 'owner_id'), 'project' => array(self::BELONGS_TO, 'Project', 'project_id'), 'comments' => array(self::HAS_MANY, 'Comment', 'issue_id'), 'commentCount' => array(self::STAT, 'Comment', 'issue_id'), ); } Also, we need to change our newly created Comment AR class to extend our custom TrackStarActiveRecord base class, so that it benefits from the logic we placed in the beforeValidate() method. Simply alter the beginning of the class definition as such: array(self::BELONGS_TO, 'User', 'create_user_id'), 'issue' => array(self::BELONGS_TO, 'Issue', 'issue_id'), ); } Creating the Comment CRUD Once we have an AR class in place, creating the CRUD scaffolding for managing the related entity is equally as easy. Again, use the Gii code generation tool's Crud Generator command with the AR class name, Comment, as the argument. Again, we have seen this many times in previous iterations, so we will leave this as an exercise for the reader. Again, if needed, refer back to Chapters 5 and 6 for all the details on using this tool to create CRUD scaffolding code. Although we will not immediately implement full CRUD operations for our comments, it is nice to have the scaffolding for the other operations in place. As long as we are logged in, we should now be able to view the autogenerated comment submission form via the following URL: http://localhost/trackstar/index.php?r=comment/create Altering the scaffolding to meet requirements As we have seen many times before, we often have to make adjustments to the autogenerated scaffolding code in order to meet the specific requirements of the application. For one, our autogenerated form for creating a new comment has an input field for every single column defined in the tbl_comment database table. Chapter 9 [ 219 ] We don't actually want all of these fields to be part of the form. In fact, we want to greatly simplify this form to have only a single input field for the comment content. What's more, we don't want the user to access the form via the above URL, but rather only by visiting an issue details page. The user will add comments on the same page where they are viewing the details of the issue. We want to build towards something similar to what is depicted in the following screenshot: In order to achieve this, we are going to alter our Issue controller class to handle the post of the comment form as well as alter the issue details view to display the existing comments and new comment creation form. Also, as comments should only be created within the context of an issue, we'll add a new method to the Issue model class to create new comments. Iteration 6: Adding User Comments [ 220 ] Adding a comment Let's start by writing a test for this new public method on the Issue model class. Open up the IssueTest.php file and add the following test method: public function testAddComment() { $comment = new Comment; $comment->content = "this is a test comment"; $this->assertTrue($this->issues('issueBug')->addComment($comment)); } This, of course, will fail until we add the method to our Issue AR class. Add the following method to the Issue AR class: /** * Adds a comment to this issue */ public function addComment($comment) { $comment->issue_id=$this->id; return $comment->save(); } This method ensures the proper setting of the comment issue ID before saving the new comment. Run the test again to ensure it now passes. With this method in place, we can now turn focus to the issue controller class. As we want the comment creation form to display from and post its data back to the IssueController::actionView() method, we will need to alter that method. We will also add a new protected method to handle the form POST request. First, alter the actionView() method to be the following: public function actionView() { $issue=$this->loadModel(); $comment=$this->createComment($issue); $this->render('view',array( 'model'=>$issue, 'comment'=>$comment, )); } Chapter 9 [ 221 ] Then add the following protected method to create a new comment and handle the form post request for creating a new comment for this issue: protected function createComment($issue) { $comment=new Comment; if(isset($_POST['Comment'])) { $comment->attributes=$_POST['Comment']; if($issue->addComment($comment)) { Yii::app()->user->setFlash('commentSubmitted',"Your comment has been added." ); $this->refresh(); } } return $comment; } Our new protected method, createComment() is responsible for handling the POST request for creating a new comment based on the user input. If the comment is successfully created, the page will be refreshed displaying the newly created comment. The changes made to IssueController::actionView() are responsible for calling this new method and also feeding the new comment instance to the view. Displaying the form Now we need to alter our view. First we are going to create a new view file to render the display of our comments and the comment input form. As we'll render this as a partial view, we'll stick with the naming conventions and begin the filename with a leading underscore. Create a new file called _comments.php under the protected/ views/issue/ folder and add the following code to that file:

author->username; ?>:

on create_ time)); ?>

Iteration 6: Adding User Comments [ 222 ] content)); ?>

---

This file expects as an input parameter an array of comment instances and displays them one by one. We now need to alter the view file for the issue detail to use this new file. We do this by opening protected/views/issue/view.php and adding the following to the end of the file:

commentCount>=1): ?>

commentCount>1 ? $model->commentCount . ' comments' : 'One comment'; ?>

renderPartial('_comments',array( 'comments'=>$model->comments, )); ?>

Leave a Comment

user->hasFlash('commentSubmitted')): ?>

user->getFlash('commentSubmitted'); ?>

renderPartial('/comment/_form',array( 'model'=>$comment, )); ?>

Here we are taking advantage of the statistical query property, commentCount, we added earlier to our Issue AR model class. This allows us to quickly determine if there are any comments available for the specific issue. If there are comments, it proceeds to render them using our _comments.php display view file. It then displays the input form that was created for us when we used the Gii Crud Generator functionality. It will also display the simple flash message set upon a successfully saved comment. Chapter 9 [ 223 ] One last change we need to make is to the comment input form itself. As we have seen many times in the past, the form created for us has an input field for every column defined in the underlying tbl_comment table. This is not what we want to display to the user. We want to make this a simple input form where the user only needs to submit the comment content. So, open up the view file that houses the input form, that is, protected/views/comment/_form.php and edit it to be simply:

beginWidget('CActiveForm', array( 'id'=>'comment-form', 'enableAjaxValidation'=>false, )); ?>

Fields with * are required.

errorSummary($model); ?>

labelEx($model,'content'); ?> textArea($model,'content',array('rows'=>6, 'cols'=>50)); ?> error($model,'content'); ?>

isNewRecord ? 'Create' : 'Save'); ?>

endWidget(); ?>

With all of this in place, we can visit an issue listing page, for example http://hostname/trackstar/index.php?r=issue/view&id=1 And we see the following comment input form at the bottom of the page: Iteration 6: Adding User Comments [ 224 ] If we attempt to submit the comment without specifying any content, we see an error as depicted in the following screenshot: And then, if we are logged in as Test User One and we submit the comment My first test comment, we are presented with the following display: Creating a recent comments widget Now that we have the ability to leave comments on issues, we are going to turn our focus to the second primary goal of this iteration. We want to display to the user a list of all of the recent comments that have been left on various issues across all of the projects. This will provide a nice snapshot of user communication activity within the application. We also want to build this small block of content in a manner that will allow it to be re-used in various different locations throughout the site. This is very much in the style of web portal applications such as news forums, weather reporting applications and sites such as Yahoo and iGoogle. These small snippets of content are often referred to as portlets, and this is why we referred to building a portlet architecture at the beginning of this iteration. Again, you can refer to http://en.wikipedia.org/wiki/Portlet for more information on this topic. Chapter 9 [ 225 ] Introducing CWidget Lucky for us, Yii is readymade to help us achieve this architecture. Yii provides a component class, called CWidget, which is intended for exactly this purpose. A Yii widget is an instance of this class (or its child class), and is a presentational component typically embedded in a view file to display self-contained, reusable user interface features. We are going to use a Yii widget to build a recent comments portlet and display it on the main project details page so we can see comment activity across all issues related to the project. To demonstrate the ease of re-use, we'll take it one step further and also display a list of project-specific comments on the project details page. To begin creating our widget, we are going to first add a new public method on our Comment AR model class to return the most recently added comments. As expected, we will begin by writing a test. But before we write the test method, let's update our comment fixtures data so that we have a couple of comments to use throughout our testing. Create a new file called tbl_comment.php within the protected/tests/fixtures folder. Open that file and add the following content: array( 'content' => 'Test comment 1 on issue bug number 1', 'issue_id' => 1, 'create_time' => '', 'create_user_id' => 1, 'update_time' => '', 'update_user_id' => '', ), 'comment2'=>array( 'content' => 'Test comment 2 on issue bug number 1', 'issue_id' => 1, 'create_time' => '', 'create_user_id' => 1, 'update_time' => '', 'update_user_id' => '', ), ); Now we have consistent, predictable, and repeatable comment data to work with. Iteration 6: Adding User Comments [ 226 ] Create a new unit test file, protected/tests/unit/CommentTest.php and add the following content: 'Comment', ); public function testRecentComments() { $recentComments=Comment::findRecentComments(); $this->assertTrue(is_array($recentComments)); } } This test will of course fail, as we have not yet added the Comment::findRecentComments() method to the Comment model class. So, let's add that now. We'll go ahead and add the full method we need, rather than adding just enough to get the test to pass. But if you are following along, feel free to move at your own TDD pace. Open Comment.php and add the following public static method: public static function findRecentComments($limit=10, $projectId=null) { if($projectId != null) { return self::model()->with(array( 'issue'=>array('condition'=>'project_id='.$projectId)))- >findAll(array( 'order'=>'t.create_time DESC', 'limit'=>$limit, )); } else { //get all comments across all projects return self::model()->with('issue')->findAll(array( 'order'=>'t.create_time DESC', 'limit'=>$limit, )); } } Chapter 9 [ 227 ] Our new method takes in two optional parameters, one to limit the number of returned comments, the other to specify a specific project ID to which all of the comments should belong. The second parameter will allow us to use our new widget to display all comments for a project on the project details page. So, if the input project id was specified, it restricts the returned results to only those comments associated with the project, otherwise, all comments across all projects are returned. More on relational AR queries in Yii The above two relational AR queries are a little new to us. We have not been using many of these options in our previous queries. Previously we have been using the simplest approach to executing relational queries: 1. Load the AR instance. 2. Access the relational properties defined in the relations() method. For example if we wanted to query for all of the issues associated with, say, project id #1, we would execute the following two lines of code: // retrieve the project whose ID is 1 $project=Project::model()->findByPk(1); // retrieve the project's issues: a relational query is actually being performed behind the scenes here $issues=$project->issues; This familiar approach uses what is referred to as a Lazy Loading. When we first create the project instance, the query does not return all of the associated issues. It only retrieves the associated issues upon an initial, explicit request for them, that is, when $project->issues is executed. This is referred to as lazy because it waits to load the issues. This approach is convenient and can also be very efficient, especially in those cases where the associated issues may not be required. However, in other circumstances, this approach can be somewhat inefficient. For example, if we wanted to retrieve the issue information across N projects, then using this lazy approach would involve executing N join queries. Depending on how large N is, this could be very inefficient. In these situations, we have another option. We can use what is called Eager Loading. Iteration 6: Adding User Comments [ 228 ] The Eager Loading approach retrieves the related AR instances at the same time as the main AR instances are requested. This is accomplished by using the with() method in concert with either the find() or findAll() methods for AR query. Sticking with our project example, we could use Eager Loading to retrieve all issues for all projects by executing the following single line of code: //retrieve all project AR instances along with their associated issue AR instances $projects = Project::model()->with('issues')->findAll(); Now, in this case, every project AR instance in the $projects array already has its associated issues property populated with an array of issues AR instances. This result has been achieved by using just a single join query. We are using this approach in both of the relational queries executed in our findRecentComments() method. The one we are using to restrict the comments to a specific project is slightly more complex. As you can see, we are specifying a query condition on the eagerly loaded issue property for the comments. Let's look at the following line: Comment::model()->with(array('issue'=>array('condition'=>'project_ id='.$projectId)))->findAll(); This query specifies a single join between the tbl_comment and the tbl_issue tables. Sticking with project id #1 for this example, the previous relational AR query would basically execute something similar to the following SQL statement: SELECT tbl_comment.*, tbl_issue.* FROM tbl_comment LEFT OUTER JOIN tbl_issue ON (tbl_comment.issue_id=tbl_issue.id) WHERE (tbl_issue. project_id=1) The added array we specify in the findAll() method simply sets an order by clause and a limit clause to the executed SQL statement. One last thing to note about the two queries we are using is how the column names that are common to both tables are disambiguated. Obviously when the two tables that are being joined have columns with the same name, we have to make a distinction between the two in our query. In our case, both tables have the create_time column defined. We are trying to order by this column in the tbl_comment table and not the one defined in the issue table. In a relational AR query in Yii, the alias name for the primary table is fixed as t, while the alias name for a relational table, by default, is the same as the corresponding relation name. So, in our two queries, we specify t.create_time to indicate we want to use the primary table's column. If we wanted to instead order by the issue create_time column, we would alter, the second query for example, as such: Chapter 9 [ 229 ] return Comment::model()->with('issue')->findAll(array( 'order'=>'issue.create_time DESC', 'limit'=>$limit, )); Completing the test Okay, now that we fully understand what our new method is doing, we need to complete testing of it. In order to fully test our new method, we need to make a few changes to our fixture data. Open each of the fixture data files: tbl_project.php, tbl_issue.php, and tbl_comment.php and ensure each of these entries is in place: Add the following code in tbl_project: 'project3'=>array( 'name' => 'Test Project 3', 'description' => 'This is test project 3', 'create_time' => '', 'create_user_id' => '', 'update_time' => '', 'update_user_id' => '', ), In tbl_issue, add the following code: 'issueFeature2'=>array( 'name' => 'Test Feature For Project 3', 'description' => 'This is a test feature issue associated with project # 3 that is completed', 'project_id' => 3, 'type_id' => 1, 'status_id' => 2, 'owner_id' => 1, 'requester_id' => 1, 'create_time' => '', 'create_user_id' => '', 'update_time' => '', 'update_user_id' => '', ), Iteration 6: Adding User Comments [ 230 ] Finally, add the following code in tbl_comment: 'comment3'=>array( 'content' => 'The first test comment on the first feature issue associated with Project #3', 'issue_id' => 3, 'create_time' => '', 'create_user_id' => '', 'update_time' => '', 'update_user_id' => '', ), We now have a total of three comments in our test database. Two of them associated with project #1 and one associated with project #3. Now we can alter our test method to test: • Requesting all comments • Limiting the number of returned comments to just two • Restricting the returned comments to only those associated with project #3 The following method tests all three scenarios: public function testRecentComments() { //retrieve all the comments for all projects $recentComments = Comment::findRecentComments(); $this->assertTrue(is_array($recentComments)); $this->assertEquals(count($recentComments),3); //make sure the limit is working $recentComments = Comment::findRecentComments(2); $this->assertTrue(is_array($recentComments)); $this->assertEquals(count($recentComments),2); //test retrieving comments only for a specific project $recentComments = Comment::findRecentComments(5, 3); $this->assertTrue(is_array($recentComments)); $this->assertEquals(count($recentComments),1); } Chapter 9 [ 231 ] We also need to ensure that our CommentTest class is using the fixture data for comments, issues, and projects. Make sure the following fixtures are defined at the top of our CommentTest class: 'Comment', 'projects'=>'Project', 'issues'=>'Issue', ); Now, if we run this test again, we should have all six assertions passing: >>phpunit unit/CommentTest.php PHPUnit 3.4.12 by Sebastian Bergmann. . Time: 0 seconds OK (1 test, 6 assertions) Armed with the knowledge of the benefits of Lazy Loading versus Eager Loading in Yii, we should make an adjustment to how the Issue model is loaded within the IssueController::actionView() method. Since we have altered the issues detail view to display our comments, including the author of the comment, we know it will be more efficient to use the Eager Loading approach to load our comments along with their respective authors when we make the call to loadModel() in this method. To do this, we can add a simple input flag to this loadModel() method to indicate whether or not we want to load the comments as well. Alter the IssueController::loadModel() method as shown below: public function loadModel($withComments=false) { if($this->_model===null) { if(isset($_GET['id'])) { if($withComments) { $this->_model=Issue::model()->with(array( 'comments'=>array('with'=>'author'))) ->findbyPk($_GET['id']); } else Iteration 6: Adding User Comments [ 232 ] { $this->_model=Issue::model()->findbyPk($_GET['id']); } } if($this->_model===null) throw new CHttpException(404,'The requested page does not exist.'); } return $this->_model; } Now we can change the call to this method in IssueController::actionView(), as such: public function actionView() { $issue=$this->loadModel(true); With this in place, we will load all of our comments, along with their respective author information, with just one database call. Creating the widget Now we are ready to create our new widget to use our new method to display our recent comments. As we previously mentioned a widget in Yii is a class that extend from the framework class CWidget or one of its child classes. We'll add our new widget to the protected/components/ directly, as the contents of this folder are already specified in the main configuration file to be auto-loaded within the application. This way we won't have to explicitly import the class every time we wish to use it. We'll name our widget RecentComments, so we need to add a php file of the same name to this directly. Add the following class definition to this newly created RecentComment. php file: _comments = Comment::model() ->findRecentComments($this->displayLimit, $this->projectId); } public function getRecentComments() { return $this->_comments; } public function run() { // this method is called by CController::endWidget() $this->render('recentComments'); } } The primary work involved when creating a new widget is to override the init() and run() methods of the base class. The init() method initializes the widget and is called after its properties have been initialized. The run() method executes the widget. In this case, we simply initialize the widget by requesting recent comments based on the $displayLimit and $projectId properties. The execution of the widget itself simply renders its associated view file, which we have yet to create. view files, by convention, are placed in views/ directly within the same folder where the widget resides, and have the same name as the widget, but start with a lowercase letter. Sticking with convention, create a new file whose fully qualified path is protected/ components/views/renderComments.php. Once created, add the following markup to that file:

getRecentComments() as $comment): ?>
author->username; ?> added a comment.
issue->name), array('issue/view', 'id'=>$comment->issue->id)); ?>

This calls the RenderComments widget's getRecentComments() method, which returns an array of comments. It then iterates over each of them displaying who added the comment and the associated issue on which the comment was left. Iteration 6: Adding User Comments [ 234 ] In order to see the results, we need to embed this widget into an existing controller view file. As previously mentioned, we want to use this widget on the projects listing page, to display all recent comments across all projects, and also on a specific project details page, to display the recent comments for just that specific project. Let's start with the project listing page. The view file responsible for displaying that content is protected/views/project/index.php. Open up that file and add the following at the bottom: widget('RecentComments'); ?> Now if we view the projects listing page http://localhost/trackstar/index. php?r=project, we see something similar to the following screenshot: We have now embedded our new recent comments data within the page simply by calling the widget. This is nice, but we can take our little widget one step further to have it display in a consistent manner with all other potential portlets in the application. We can do this by taking advantage of another class provided to us by Yii, CPortlet. Chapter 9 [ 235 ] Introducing CPortlet CPortlet is part of zii, the official extension class library that comes packaged with Yii. It provides a nice base class for all portlet-style widgets. It will allow us to render a nice title as well as consistent HTML markup, so that all portlets across the application can be easily styled in a similar manner. Once we have a widget that renders content (like our RecentComments widget), we can simply use the rendered content of our widget as the content for CPortlet, which itself is a widget, as it also extends from CWidget. We can do this by placing our call to the RecentComments widget between a beginWidget() and an endWiget() call for CPortlet, as such: beginWidget('zii.widgets.CPortlet', array( 'title'=>'Recent Comments', )); $this->widget('RecentComments'); $this->endWidget(); ?> Since CPortlet provides a title property, we set it to be something meaningful for our portlet. We then use the rendered content of the RecentComments widget to drive the content for the porlet widget. The end result of this is depicted in the following screenshot: Iteration 6: Adding User Comments [ 236 ] This is not a huge change from what we had previously, but we have now placed our content into a consistent container that is already being used throughout the site. Notice the similarity between the right column menu content block and our newly created recent comments content block. I am sure it will come as no surprise to you that this right column menu block is also displayed within a CPortlet container. Taking a peek in protected/views/layouts/column2.php, which is a file that the yiic webapp command autogenerated for us when we initially created the application, reveals the following code: beginWidget('zii.widgets.CPortlet', array( 'title'=>'Operations', )); $this->widget('zii.widgets.CMenu', array( 'items'=>$this->menu, 'htmlOptions'=>array('class'=>'operations'), )); $this->endWidget(); ?> So it seems that the application has been taking advantage of portlets all along. Adding our widget to another page Let's also add our portlet to the project details page, and restrict the comments to just those associated with the specific project. Add the following to the bottom of the protected/views/project/view.php file: beginWidget('zii.widgets.CPortlet', array( 'title'=>'Recent Project Comments', )); $this->widget('RecentComments', array('projectId'=>$model->id)); $this->endWidget(); ?> This is basically the same thing we added to the project listings page, except we are initializing the RecentComments widget's $projectId property by adding an array of name=>value pairs to the call. Now if we visit a specific project details page, we should see something similar to the following screenshot: Chapter 9 [ 237 ] This screenshot shows the details page for project #3, which has one associated issue with just one comment on that issue, as depicted in the picture. You may need to add a few issues and comments on those issues in order to generate a similar display. We now have a way to display recent comments with a few different configurable parameters anywhere throughout the site in a consistent and easily maintainable manner. Summary With this iteration, we have started to flesh out our Trackstar application with functionality that has come to be expected of most user-based web applications today. The ability for users to communicate with each other within the application is an essential part of a successful issue management system. As we created this essential feature, we were able to deeper look into how to write relational AR queries. We were also introduced to content components called widgets and portlets. This introduced us to an approach to developing small content blocks and being able to use them anywhere throughout the site. This approach greatly increases reuse, consistency, and ease of maintenance. In the next iteration, we'll build upon the recent comments widget created here, and expose the content generated by our widget as an RSS feed to allow users to track application or project activity without having to visit the application. Iteration 7: Adding an RSS Web Feed In the previous iteration, we added the ability for the user to leave comments on issues and to display a list of these comments utilizing a portlet architecture to allow us to easily and consistently display that listing anywhere throughout the application. In this iteration, we are going to build upon this feature and expose this list of comments as an RSS data feed. Furthermore, we are going to use the existing feed functionality available in another open source framework, the Zend Framework, to demonstrate just how easy it is for a Yii application to integrate with other third-party tools. Iteration planning The goal of this iteration is to create an RSS feed using the content created from our user generated comments. We should allow users to subscribe to a comment feed that spans all projects as well as subscribe to individual project feeds. Luckily, the widget functionality we built previously has the capability to return a list of recent comments across all projects, as well as restrict the data to one specific project. So, we have already coded the appropriate methods to access the needed data. The bulk of this iteration will focus on putting that data in the correct format to be published as an RSS feed, and adding links to our application to allow users to subscribe to these feeds. The following is a list of high-level tasks we will need to complete in order to achieve these goals: • Download and install Zend Framework into the Yii application • Create a new action in a controller class to respond to the feed request and return the appropriate data in an RSS format Iteration 7: Adding An RSS Web Feed [ 240 ] • Alter our URL structure for ease of use • Add our newly created feed to both the projects listings page, as well as to each individual project details page As always, be sure to run the full suite of unit tests prior to making any changes to ensure everything that is still working as expected. A little background: Content Syndication, RSS, and Zend Framework Web Content Syndication has been around for many years, but has recently gained enormous popularity. The term Web Content Syndication refers to publishing information in a standardized format so that it can easily be used by other websites and easily consumed by reader applications. Many news sites have long been electronically syndicating their content, but the massive explosion of web logs (also known as blogs) across the Internet has turned Content Syndication (also known as known as feeds) into an expected feature of almost every website. Our TrackStar application will be no exception. RSS is an acronym that stands for Really Simple Syndication. It is an XML format specification that provides a standard for Web Content Syndication. There are other formats that could be used, but due to the overwhelming popularity of RSS among most websites, we will focus on delivering our feed in this format. Zend is known as "The PHP Company". Their founders are key contributors to the core PHP language and the company focuses on creating products to help improve the entire PHP application development life-cycle experience. They provide products and services to help with configuration and installation, development, deployment and with production application administration and maintenance. One of the products they offer to assist in application development is the Zend Framework. The framework can be used as a whole to provide an entire application foundation, much in the same way we are using Yii for our TrackStar application, or piece-meal by utilizing single feature components of the framework's library. Yii is flexible enough to allow us to use pieces of other frameworks. We will be using just one component of the Zend framework library, called Zend_Feed, so that we don't have to write all of the underlying "plumbing" code to generate our RSS formatted web feeds. For more on Zend_Feed, visit http://www.zendframework.com/manual/en/zend. feed.html Chapter 10 [ 241 ] Installing Zend Framework As we are using the Zend Framework to help support our RSS needs, we first need to download and install the framework. To get the latest version, visit http://framework.zend.com/download/latest. We will only be utilizing a single component of this framework, Zend_Feed, so the minimal version of the framework will suffice. When you expand the downloaded framework file, you should see the following high-level folder and file structure: INSTALL.txt LICENSE.txt README.txt bin/ library/ In order to use this framework within our Yii application, we need to move some of the files within our application's folder structure. Let's create a new folder under the /protected folder within our application called vendors/. Then, move the Zend Framework folder /library/Zend underneath this newly created folder. After everything is in place, ensure that protected/vendors/Zend/Feed.php exists in the TrackStar application. Using Zend_Feed Zend_Feed is a small component of the Zend Framework that encapsulates all of the complexities of creating web feeds behind a simple, easy-to-use interface. It will help us get a working, tested, RSS compliant data feed in place in very little time. All we will need to do is format our comment data in a manner expected by Zend_Feed, and it does the rest. We need a place to house the code to handle the requests for our feed. We could create a new controller for this, but to keep things simple, we'll just add a new action method to our main CommentController.php file to handle the requests. Rather than add to the method a little at a time, we'll list the entire method here, and then talk through what it is doing. Iteration 7: Adding An RSS Web Feed [ 242 ] Open up CommentController.php and add the following public method: public function actionFeed() { if(isset($_GET['pid'])) $projectId = intval($_GET['pid']); else $projectId = null; $comments = Comment::model()->findRecentComments(20, $projectId); //convert from an array of comment AR class instances to an name=>value array for Zend $entries=array(); foreach($comments as $comment) { $entries[]=array( 'title'=>$comment->issue->name, 'link'=>CHtml::encode($this->createAbsoluteUrl('issue/ view',array('id'=>$comment->issue->id))), 'description'=> $comment->author->username . ' says:
' . $comment->content, 'lastUpdate'=>strtotime($comment->create_time), 'author'=>$comment->author->username, ); } //now use the Zend Feed class to generate the Feed // generate and render RSS feed $feed=Zend_Feed::importArray(array( 'title' => 'Trackstar Project Comments Feed', 'link' => $this->createUrl(''), 'charset' => 'UTF-8', 'entries' => $entries, ), 'rss'); $feed->send(); } This is all fairly simple. First we check the input request querystring for the existence of a pid parameter, which we take to indicate a specific project ID. Remember that we want to optionally allow the data feed to restrict the content to comments associated with a single project. Next we use the same method that we used in the previous iteration to populate our widget to retrieve a list of up to 20 recent comments, either across all projects, or if the project ID is specified, specific to that project. Chapter 10 [ 243 ] You may remember that this method returns an array of Comment AR class instances. We iterate over this returned array and convert the data into the format expected by the Zend_Feed component. Zend_Feed expects a simple array containing elements which are themselves arrays containing the data for each comment entry. Each individual entry is a simple associative array of name=>value pairs. To comply with the specific RSS format, each of our individual entries must minimally contain a title, a link, and a description. We have also added two optional fields, one called lastUpdate, which Zend_Feed translates to the RSS field, pubDate, and one to specify the author. There are a few extra helper methods we take advantage of in order to get the data in the correct format. For one, we use the controller's createAbsoluteUrl() method, rather than just the createUrl() method in order to generate a fully qualified URL. Using createAbsoluteUrl() will generate a link like the following http://localhost/trackstar/index.php?r=issue/view &id=5 as opposed to just /index.php?r=issue/view&id=5. Also, to avoid errors such as "unterminated entity reference" being generated from PHP's DOMDocument::createElement(), which is used by Zend_Feed to generate the RSS XML, we need to convert all applicable characters to HTML entities by using our handy helper function, CHTML::encode. So, we encode the link such that a URL that looks like: http://localhost/trackstar/index.php?r=issue/view&id=5 will be converted to: http://localhost/trackstar/index.php?r=issue/view&id=5 Once all of our entries have been properly populated and formatted, we use Zend_ Feed's importArray() method which expects an array to construct the RSS feed. Finally, once the Zend feed class is built from the input array of entries and returned, we call the send() method on that class. This returns the properly formatted RSS XML and appropriate headers to the client. We need to make a couple of configuration changes to the CommentController.php file and class before this will work. First, we need to import the /vendors/Zend/ Feed.php file as well as the Rss.php file under the Feed/ folder. Add the following statements to the top of CommentController.php: Yii::import('application.vendors.*'); require_once('Zend/Feed.php'); require_once('Zend/Feed/Rss.php'); Iteration 7: Adding An RSS Web Feed [ 244 ] Then, alter the CommentController::accessRules() method to allow any user to access our newly added actionFeed() method: public function accessRules() { return array( array('allow', // allow all users to perform 'index' and 'view' actions 'actions'=>array('index','view', 'feed'), 'users'=>array('*'), ), … This is really all there is to it. If we now navigate to http://localhost/trackstar/ index.php?r=comment/feed, we can view the results of our effort. As browsers handle the display of RSS feeds differently, what you see might differ from the following screenshot. The following screenshot is what you should see you are if viewing the feed in the Firefox browser: Creating user friendly URLs So far, throughout the development process, we have been using the default format of our Yii application URL structure. This format, discussed back in Chapter 2, uses a querystring approach. We have the main parameter, 'r', which stands for route, followed by a controllerID/actionID pair, and then optional querystring Chapter 10 [ 245 ] parameters as needed by the specific action methods being called. The URL we created for our new feed is no exception. It is a long, cumbersome and dare we say ugly URL. There has got to be a better way! Well, in fact, there is. We could make the above URL look cleaner and more self-explanatory by using the so-called path format, which eliminates the query string and puts the GET parameters into the path info part of URL: Taking our comment feed URL as an example, instead of: http://localhost/trackstar/index.php?r=comment/feed we would have: http://localhost/trackstar/index.php/comment/feed/ What's more, we don't even need to always specify the entry script for each request. We can also take advantage of Yii's request routing configuration options to remove the need to specify the controllerID/actionID pair as well. Our request could then look like: http://localhost/trackstar/commentfeed Also, it is common, especially with feed URL, to have the .xml extension specified at the end. So, it would be nice if we could alter our URL to look like: http://localhost/trackstar/commentfeed.xml This greatly simplifies the URL for users and is also an excellent format for URLs to be properly indexed into major search engines (often referred to as "search engine friendly URLs"). Let's see how we can use Yii's URL management features to alter our URL to match the desired format. Using the URL manager The built-in URL manager in Yii is an application component that can be configured in the protected/config/main.php file. Let's open up that file and add a new URL manager component declaration to the components array: 'urlManager'=>array( 'urlFormat'=>'path', ), As long as we stick with the default and name it urlManager, we do not need to specify the class of the component because it is pre-declared to be CUrlManager.php in the CWebApplication.php framework class. Iteration 7: Adding An RSS Web Feed [ 246 ] With this one simple addition, our URL structure has changed to the 'path' format throughout the site. For example, previously if we wanted to view, say, a specific issue whose ID is 1, we would make the request using the following URL: http://localhost/trackstar/index.php?r=issue/view&id=1 but with these changes in place, our URL now looks like: http://localhost/trackstar/index.php/issue/view/id/1 You'll notice the changes we have made have affected all the URLs generated throughout the application. To see this, visit our feed again by going to http://localhost/trackstar/index.php/comment/feed/. We notice that all of our issue links have been reformatted to this new structure for us. This is all thanks to our consistent use of the controller methods and other helper methods to generate our URLs. We can alter the URL format in just one single configuration file, and the changes will automatically propagate throughout the application. Our URLs are looking better, but we still have the entry script, index.php, specified and we are not yet able to append the .xml suffix on the end of our feed URL. So, we'll hide the index.php as part of the URL, and also setup the request routing to understand that a request for commentfeed.xml actually means a request for the actionFeed() method within the CommentController.php class. Let's actually tackle the latter, first. Configuring routing rules Yii's URL manager allows us to specify rules that define how URLs are parsed and created. A rule consists of defining a route and a pattern. The pattern is used to match on the path information part of the URL to determine which rule is used for parsing or creating URLs. The pattern may contain named parameters using the syntax ParamName:RegExp. When parsing a URL, a matching rule will extract these named parameters from the path info and put them into the $_GET variable. When a URL is being created by the application, a matching rule will extract the named parameters from $_GET and put them into the path info part of the created URL. If a pattern ends with '/*', it means additional GET parameters may be appended to the path info part of the URL. To specify URL rules, set the set the CUrlManager's rules property as an array of rules in the format pattern=>route. As an example, let's look at the following two rules: 'urlManager'=>array( 'urlFormat'=>'path', 'rules'=>array( Chapter 10 [ 247 ] 'issues'=>'issue/index', 'issue//*'=>'issue/view', ) There are two rules specified in the above code. The first rule says that if the user requests the URL http://localhost/trackstar/index.php/issues, it should be treated as http://localhost/trackstar/index.php/issue/index and the same applies when constructing such a URL. The second rule contains a named parameter id which is specified using the syntax. It says that, for example, if the user requests the URL http://localhost/trackstar /index.php/issue/1, it should be treated as http://localhost/trackstar/index.php/issue/view?id=1. The same also applies when constructing such a URL. The route can also be specified as an array itself to allow the setting of other attributes such as the URL suffix and whether or not the route should be considered as case sensitive. We'll take advantage of these as we specify the rule for our comment feed. Let's add the following rule to our urlManager application component configuration: 'urlManager'=>array( 'urlFormat'=>'path', 'rules'=>array( 'commentfeed'=>array('comment/feed', 'urlSuffix'=>'.xml', 'caseSensitive'=>false), ), ), Here, we have used the urlSuffix attribute to specify our desired URL .xml suffix. Now we can access our feed by using the following URL: http://localhost/trackstar/index.php/commentFeed.xml Removing the entry script from the URL Now we just need to remove the index.php from the URL. This is done in two steps: 1. Alter the web server configuration to re-route all requests that don't correspond to existing files or directories to index.php. 2. Set the UrlManager's showScriptName property to false. Iteration 7: Adding An RSS Web Feed [ 248 ] The first takes care of the how the application routes the requests, the second takes care of how URLs will be created throughout the application. As we are using Apache HTTP Server, we can perform the first step by by creating a .htaccess file in the application root folder and adding the following directives to that file: Options +FollowSymLinks IndexIgnore */* RewriteEngine on # if a directory or a file exists, use it directly RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d # otherwise forward it to index.php RewriteRule . index.php Note: This approach is only for use with the Apache HTTP Server. You will need to consult your web server's re-write rules documentation if you are using a different web server. Also note that this information could be placed in the Apache configuration file as an alternative to using the .htaccess file approach. With the .htaccess file in place, we can now visit our feed by navigating to http://localhost/trackstar/commentfeed.xml (or http://localhost/ trackstar/commentFeed.xml as we set the case-sensitivity to false) However, even with this in place, if we use one of the controller methods or one of our CHTML helper methods in our application to create our URL, say by executing the following in a controller class: $this->createAbsoluteUrl('comment/feed'); it will generate the following URL, with index.php still in the URL: http://localhost/trackstar/index.php/commentfeed.xml In order to instruct it to not use the entry script name when generating URLs, we need to set that property on the urlManager component. We do this again in the main.php config file as such: 'urlManager'=>array( 'urlFormat'=>'path', 'rules'=>array( Chapter 10 [ 249 ] 'commentfeed'=>array('site/commentFeed', 'urlSuffix'=>'.xml', 'caseSensitive'=>false), ), 'showScriptName'=>false, ), In order to handle the addition of the project ID in the URL, which we need to restrict the comment feed data to comments associated with specific projects, we need to add one other rule: 'urlManager'=>array( 'urlFormat'=>'path', 'rules'=>array( '/commentfeed'=>array('site/ commentFeed', 'urlSuffix'=>'.xml', 'caseSensitive'=>false), 'commentfeed'=>array('site/commentFeed', 'urlSuffix'=>'.xml', 'caseSensitive'=>false), ), 'showScriptName'=>false, ), This rule also uses the syntax to specify a pattern to allow for a project ID to be specified before the commentfeed.xml part of the URL. With this rule in place, we can restrict our RSS feed to comments specific to a project. For example, if we just want the comments associated with project # 2, the URL format would be: http://localhost/trackstar/2/commentfeed.xml Adding the feed links Now that we have created our feed and altered the URL structure to make it more user and search engine friendly, we need to add the ability for users to subscribe to the feed. One way to do this is to add the following code before rendering the pages in which we want to add the RSS feed link. Let's do this for both the project listing page as well as a specific project details page. We'll start with the project listings page. This page is rendered by the ProjectController::actionIndex() method. Alter that method as such: public function actionIndex() { $dataProvider=new CActiveDataProvider('Project'); Yii::app()->clientScript->registerLinkTag( Iteration 7: Adding An RSS Web Feed [ 250 ] 'alternate', 'application/rss+xml', $this->createUrl('comment/feed')); $this->render('index',array( 'dataProvider'=>$dataProvider, )); } The above highlighted code adds the following to the tag of the rendered HTML: In many browsers, this will automatically generate a little RSS feed icon in the address bar. The following screenshot depicts what this icon looks like in the Firefox 3.6 address bar: We make a similar change to add this link to a specific project details page. The rendering of these pages is handled by the ProjectController::actionView() method. Alter that method to be the following: public function actionView() { $issueDataProvider=new CActiveDataProvider('Issue', array( 'criteria'=>array( 'condition'=>'project_id=:projectId', 'params'=>array(':projectId'=>$this- >loadModel()->id), ), 'pagination'=>array( 'pageSize'=>1, ), )); Yii::app()->clientScript->registerLinkTag( 'alternate', 'application/rss+xml', $this->createUrl('comment/feed',array('pid'=>$this- >loadModel()->id))); Chapter 10 [ 251 ] $this->render('view',array( 'model'=>$this->loadModel(), 'issueDataProvider'=>$issueDataProvider, )); } This is almost the same as what we added to the index method, except that we are specifying the project ID so that our comment entries are restricted to just those associated with that project. A similar icon will now display in the address bar on our project details page. Clicking on one of these icons allow the user to subscribe to these comment feeds. Summary This iteration demonstrated just how easy it is to integrate Yii with other external frameworks. We specifically used the popular Zend Framework to demonstrate this and were able to quickly add an RSS compliant web feed to our application. Though we specifically used Zend_Feed, we really demonstrated how to integrate any of the Zend Framework components into the application. This further extends the already extensive feature offering of Yii, making Yii applications incredibly feature rich. We also learned about the URL Management features within Yii and altered our URL format throughout the application to be more user and search engine friendly. This is a first step in improving upon the look and feel of our application. Something we have very much neglected up to this point. Turning our focus to styles, themes, and generally making things pretty is the focus of the next iteration. Iteration 8: Making it Pretty - Design, Layout, Themes, and Internationalization(i18n) In the previous iteration, we started to add a little beauty to our application by making our URLs more attractive to both, the user and to search engine bots that crawl the site. In this iteration, we are going to turn more focus to the look and feel of our application by covering the topics of page layouts and themes in Yii. Though we will live up to the title of this chapter by changing the look of our application to something we believe is slightly better looking, we will be focused on the approach one takes and the tools available to help design the front-end of a Yii application rather than design itself. So this iteration will focus more on how you can make your applications pretty, rather than spending a lot of time specifically designing our TrackStar application. Iteration planning This iteration aims to focus on the frontend. We want to create a new look for our site that is reusable and able to be implemented dynamically. We also want to accomplish without overwriting or otherwise removing our current design. Also, we are going to dig into the internationalization features of Yii, so we need to clearly understand how to accommodate application users from different geographic regions. Iteration 8: Making it Pretty- Design, Layout, Themes, and Internationalization(i18n) [ 254 ] The following is a list of high-level tasks that we will need to complete in order to achieve our goals: • Create a new theme for our application by creating new layout, CSS and other asset files for providing the application with a new front-end design • Use the internationalization and localization features of Yii to help translate a portion of our application to a new language Designing with layouts One thing that you may have noticed is that we have added a lot of functionality to our application without adding any explicit navigation to access this functionality. Our home page has not yet changed from the default application we built. We still have the same navigation items as we did when we first created our new application. We need to change our basic navigation to better reflect the underlying functionality present in the application. Thus far, we have not fully covered how our application is using all of the view files responsible for displaying the content. We know that our view files are responsible for our data display and housing the HTML sent back for each page request. When we create new controller actions, we also often create new views to handle the display of the returned content from these action methods. Most of these views are very specific to the action methods they support and not used across multiple pages. However, there are some things, like the main menu navigation, that are used across multiple pages throughout the site. These types of UI components are better suited to reside in what are called layout files. A layout in Yii, is a special view file used to decorate other view files. Layouts typically contain markup or other user interface components that are common across multiple view files. When using a layout to render a view file, Yii embeds the view file into the layout. Chapter 11 [ 255 ] Specifying a layout There are two main places where a layout can be specified. One is the property called $layout of the CWebApplication itself. This defaults to protected/views/ layouts/main.php if not otherwise explicitly specified. As is the case with all application settings, this can be overridden in the main config file, protected/ config/main.php. For example, if we created a new layout file, protected/views/ layouts/newlayout.php, and wanted to use this new file as our application-wide layout file, we could alter our main config file to set the layout property as such: return array( 'layout'=>'newlayout', The filename is specified without the .php extension and is relative to the $layoutPath property of CWebApplication, which defaults to Webroot/ protected/views/layouts (which itself could be overridden in a similar manner if this location does not suit your application's needs). The other place to specify the layout is by setting the $layout property of the controller class. This allows for more granular control of the layout on a controller- by-controller basis. This is the way it was specified when we generated the initial application. Using the yiic tool to create our initial application automatically created a controller base class, Webroot/protected/components/Controller.php, from which all of our other controller classes extend. Opening up this file reveals that the $layout property has been set to "column1". Setting the layout file at the more granular controller level will override the setting in the CWebApplication class. Applying and using a layout The use of a layout file is implicit in the call to the CController::render() method. That is, when you make the call to the render() method to render a view file, Yii will embed the contents of the view file into the layout file specified in either the controller class, or the one specified at the application level. You can avoid applying any layout decoration of the rendered view file by calling the CController::renderPartial() method instead. As previously mentioned, a layout file is typically used to decorate other view files. One example use of a layout is to provide a consistent header and footer layout to each and every page. When the render() method is called, what happens behind the scenes is first a call to renderPartial() on the specified view file. The output of this is stored in a variable called $content, which is then made available to the layout file. So, a simple layout file might look like the following: Iteration 8: Making it Pretty- Design, Layout, Themes, and Internationalization(i18n) [ 256 ]

Some Header Content Here

Some Footer Content Here

In fact, let's try this out. Create a new file called newlayout.php and place it in the default folder for layout files, /protected/views/layouts/. Add the above HTML content to this file and save it. Now we'll put this to use by altering our site controller to use this new layout. Open up SiteController.php and override the layout property set in the base class by explicitly adding it to this class, as such: class SiteController extends Controller { public $layout='newlayout'; This will set the layout file to newlayout.php, but only for this controller. Now, every time we make the call to the render() method within SiteController, the newlayout.php layout file will be used. One page that SiteController is responsible for rendering is the login page. Let's take a look at that page to verify these changes. If we navigate to http://localhost/trackstar/site/login (assuming we are not already logged in), we will see something similar to the following screenshot: Chapter 11 [ 257 ] If we simply comment out the $layout attribute we just added, and refresh the login page again, we are back to using the original main.php layout and our page is now back to what it looked like before. Deconstructing the main.php layout file So far, all of our application pages have been using the main.php layout file to provide the primary layout markup. Before we go making changes to our page layout and design, it would serve us well to take a closer look at this main layout file. The following is a listing of the entire contents of that file:

name); ?>

widget('zii.widgets.CMenu',array( 'items'=>array( array('label'=>'Home', 'url'=>array('/site/index')), array('label'=>'About', 'url'=>array('/site/page', 'view'=>'about')), array('label'=>'Contact', 'url'=>array('/site/contact')), array('label'=>'Login', 'url'=>array('/site/login'), 'visible'=>Yii::app()->user->isGuest), array('label'=>'Logout ('.Yii::app()->user->name.')', 'url'=>array('/site/logout'), 'visible'=>!Yii::app()->user->isGuest) ), )); ?>

widget('zii.widgets.CBreadcrumbs', array( 'links'=>$this->breadcrumbs, )); ?>

Copyright © by My Company.
All Rights Reserved.

Chapter 11 [ 259 ] We'll walk through this starting at the top. The first five lines probably look somewhat familiar to you. These lines define a standard HTML document type declaration, followed by a starting element, then the start of our element. Within the tag, we first have a meta tag to declare the standard, and very important, XHTML- compliant UTF-8 character encoding, followed by another tag that specifies English as the primary language in which the website is written. Introducing the Blueprint CSS framework The next several lines, beginning with the comment may be less familiar to you. Another great thing about Yii is that it utilizes other best-in-breed frameworks, when appropriate, and the Blueprint CSS framework is one such example. The Blueprint CSS framework was included in the application as a by-product of using the yiic tool when we initially created our application. It is included to help standardize the CSS development. Blueprint is a CSS Grid framework. It helps standardize your CSS, provides cross-browser compatibility, and provides consistency in HTML element placement helping reduce CSS errors. It comes with many screen and print-friendly layout definitions and helps jumpstart your design by providing much of the css you need to get something that looks good and in place quickly. For more on the Blueprint framework, visit http://www.blueprintcss.org/. So, the following lines of code are required by and specific to the Blueprint CSS framework: Iteration 8: Making it Pretty- Design, Layout, Themes, and Internationalization(i18n) [ 260 ] Understanding the Blueprint installation Yii by no means requires the use of Blueprint. However, as the default application generated does include the framework, understanding its installation and use will be beneficial. The typical installation of Blueprint involves first downloading the framework files, and then placing three of its .css files into the Yii application's main CSS folder. If we take a peek under the main Webroot/css folder within our TrackStar application, we already see the inclusion of these three files: • ie.css • print.css • screen.css So, luckily for us, the basic installation has already been completed as a consequence of our using the yiic webapp command to generate our application. In order to take advantage of the framework, the above tags needs to be placed under the tag for each web page. This is why these declarations are made in the layout file. The next two tags: define some custom css definitions used to provide some layout declarations in addition to the ones specified in the Blueprint files. You should always place any custom ones below the ones provide by Blueprint, so that your custom declarations take precedence. Setting the page title Setting a specific and meaningful page title on a per page basis is important to properly indexing your website pages in search engines and helpful to users who want to bookmark specific pages of your site. The next line in our main layout file specifies the page title in the browser: Chapter 11 [ 261 ] Remember that $this in a view file refers to the controller class that initially rendered the view. The $pageTitle attribute is defined down in the Yii's CController base class and will default to the action name followed by the controller name. This is easily customized in the specific controller class, or even within each specific view file. Defining a page header It is often the case that websites are designed to have consistent header content repeated across many pages. The next few lines in our main layout file define the area for a page header:

name); ?>

The first

tag with a class of "container" is required by the Blueprint framework in order to display the content as a grid. Again, using the Blueprint CSS Grid framework, or any other CSS framework is not at all a requirement of Yii. It is just there to help you jumpstart your design layout if desired. The next three lines layout the first of the main content we see on these pages. It displays the name of the application in large letters. So far, this has been displaying the text 'My Web Application'. I am sure that has been driving some of you crazy. Although we may change this later to use a logo image, let's go ahead and change this to the real name of our application, 'TrackStar'. We could hardcode this name right here in the HTML. However, if we alter our application configuration to reflect our new name, the changes will propagate everywhere throughout the site wherever Yii::app()->name is being used. I am sure you could make this simple change in your sleep at this point. Simply open up the main configuration file where our application configuration settings are defined, /protected/config/main.php and change the value of the 'name' property from: 'name'=>'My Web Application', To: 'name'=>'TrackStar' Iteration 8: Making it Pretty- Design, Layout, Themes, and Internationalization(i18n) [ 262 ] Save the file, refresh your browser and the header on the home page should now look something similar to the following screen: One thing we immediately notice in the above image is that the change has been made in two places. It just so happens that the view file responsible for our home page content, /protected/views/site/index.php, also uses the application name property. As we made the change in the application configuration file, it is reflected in both places. Displaying menu navigation items The main site navigation controls are often repeated across multiple pages in a web application, and housing this in a layout makes it easy to reuse. The next block of markup and code in our main layout file defines the top-level menu items:

widget('zii.widgets.CMenu',array( 'items'=>array( array('label'=>'Home', 'url'=>array('/site/index')), array('label'=>'About', 'url'=>array('/site/page', 'view'=>'about')), array('label'=>'Contact', 'url'=>array('/site/contact')), array('label'=>'Login', 'url'=>array('/site/login'), 'visible'=>Yii::app()->user->isGuest), array('label'=>'Logout ('.Yii::app()->user->name.')', 'url'=>array('/site/logout'), 'visible'=>!Yii::app()->user->isGuest) ), )); ?>

Chapter 11 [ 263 ] Here we see that one of the official Zii extensions, called CMenu, is being used. We introduced Zii back in Chapter 9. To jog your memory, the Zii extension library is a set of extensions developed by the Yii developer team. This library comes packaged with the download of the Yii Framework. Any of these extensions are easily used within a Yii application by simply referring to the desired extension class file using a path alias in the form of zii.path.to.ClassName. The root alias, zii, is predefined by the application, and the rest of the path is relative to this framework folder. So, as this Zii menu extension resides on your filesystem at Path-to-your-Yii- Framework/zii/widgets/CMenu.php, we can simply use zii.widgets.CMenu when referring to this in our application code. Without having to know too much about the specifics of CMenu, we can see it that it takes in an array of associative arrays that provide the menu item label, a URL to which that item should link, and an optional third value, visible, that can be set to a boolean value indicating whether or not that menu item should display. This is used here when defining the 'login' and 'logout' menu items. Obviously, we only want the 'login' menu item to display as a clickable link if the user is not already logged in. And, conversely, we would only want the "Logout" menu link to display if the user is already logged-in. The use of the visible element in the array that defines these menu items allows you to display these links dynamically based on whether the user is logged in or not. The use of Yii::app()->user->isGuest is used for this. This returns true if the user is not logged in (that is, they are a guest of the application) or false if the user is logged in. I am sure that you have already noticed that the 'login' option turns into a 'logout' option in our application's main menu whenever you are logged in, and vice versa. Let's update our menu to provide a way to navigate to our specific TrackStar functionality. First off, we don't want anonymous users to be able to access any real functionality except the login. So we want to make sure that the login page is more or less the home page for anonymous users. Also, the main home page for logged-in users should just be a listing of their projects. We'll achieve this by making the following changes: 1. Change our default home URL for the application to be the project listing page, rather than just site/index as it is now. 2. Change the default action within our default controller, SiteController, to be the login action. This way, any anonymous user that visits the top-level URL, http://localhost/trackstar/, will be redirected to the login page. 3. Alter our actionLogin() method to redirect the user to the project listing page if they are already logged in. 4. Change the 'home' menu item to read 'project', and change the URL to be the project listing page. Iteration 8: Making it Pretty- Design, Layout, Themes, and Internationalization(i18n) [ 264 ] These are actually very simple changes to make. Starting at the top, we can change the 'homeUrl' application property in our main application configuration file. Open up protected/config/main.php and add the following name=>value pair to the returned array: 'homeUrl'=>'/trackstar/project', This is all that is needed to make that change. For the next change, open up protected/controllers/SiteController.php and add the following to the top of the controller class: public $defaultAction = 'login'; This sets the default action to be 'login'. Now if you visit your top-level URL for the application, http://localhost/trackstar/, you should be taken to the login page. The only issue with this is that you will continue to be taken to the login page from this top-level URL regardless of whether you are already logged in or not. Let's fix this by implementing step 3 above. Change the actionLogin() method within SiteController to include the following code at the beginning of the method: public function actionLogin() { if(!Yii::app()->user->isGuest) { $this->redirect(Yii::app()->homeUrl); } This will redirect all logged-in users to the application homeUrl that we just previously set to be the project listing page. Finally, let's alter the input array to our CMenu widget to change the specification for the "Home" menu item. Alter that block of code in the main.php layout file and replace: array('label'=>'Home', 'url'=>array('/site/index')), with: array('label'=>'Projects', 'url'=>array('/project')), With this replacement, all of our previously outlined changes are in place. If we now visit the TrackStar application as an anonymous user, we are directed to the login page. If we click on the Projects link, we are still directed to the login page. We can still access the About and Contact pages, which is fine for an anonymous user. If we log in we are directed to the project listing page. Now if we click the Projects link, we are allowed to see the project listings. Chapter 11 [ 265 ] Creating a breadcrumb navigation Turning back to our main.php layout file, the three lines of code that follow our menu widget define another Zii extension widget called CBreadcrumbs: widget('zii.widgets.CBreadcrumbs', array( 'links'=>$this->breadcrumbs, )); ?> This widget is used to display a list of links indicating the position of the current page, relative to other pages, in the whole website. For example, a linked navigation list of the format: Projects >> Project 1 > > Edit indicates the user is viewing an Edit page for Project 1. This is helpful for the user to find their way back to where they started, which is a listing of all the projects, as well as easily see where they are in the website page hierarchy. This is why it is referred to as a breadcrumb. Many websites implement this type of UI navigational component in their design. To use this widget, we need to configure its links property, which specifies the links to be displayed. The expected value for this property is an array that defines the breadcrumb path from a starting point, down to the specific page being viewed. Using our previous example, we could specify the links array as such: array( 'Projects'=>array('project/index'), 'Project 1'=>array('project/view','id'=>1), 'Edit', ) The breadcrumbs widget, by default, adds in the very top level "Home" link automatically, based on the application configuration setting homeUrl. So, what would be generated from the above would be a breadcrumb like: Home >> Projects >> Project 1 >> Edit Iteration 8: Making it Pretty- Design, Layout, Themes, and Internationalization(i18n) [ 266 ] As we explicitly set our application $homeUrl property to be the project listings page, our first two links are the same in this case. The code in the layout file sets the link property to be the $breadcrumbs property of the controller class that is rendering the view. You can see this explicitly being set in several of the view files that were autogenerated for us when we created our controller files using the Gii code generation tool. For example, if you take a look at protected/views/project/ update.php, you see at the very top of that file the following: breadcrumbs=array( 'Projects'=>array('index'), $model->name=>array('view','id'=>$model->id), 'Update', ); And if we navigate to that page in the site, we see the following navigational breadcrumb generated, just below the main navigation: Specifying the content being decorated by the layout The next line in the layout file is where the content of the view file that is being decorated by this layout file is placed: As was discussed earlier in this chapter, when you use $this->render() in a controller class to display a certain view file, the use of a layout file is implied. Part of what this method does is to place all of the content in the specific view file being rendered into a special variable called $content, which is then made available to the layout file. So, if we again take our project update view file as an example, the contents of $content would be the rendered content contained in the file protected/views/project/update.php. Chapter 11 [ 267 ] Defining the footer Just as with the header area, it is often the case that websites are designed to have consistent footer content repeated across many pages The final few lines of our main.php layout file define a consistent footer for very page:

Copyright © by My Company.
All Rights Reserved.

There is nothing special going on here but we should go ahead and update it to reflect our specific site. We can leave the Powered by Yii Framework line in there to help promote this great framework. So, just change the "My Company" in the above code to "TrackStar", and we're done. Refreshing the pages in the site now displays a consistent footer as depicted in the following figure: Nesting the layouts Though it is true that the original layout we have been seeing on our pages is utilizing the file protected/layouts/main.php, that is not the whole story. When our initial application was created, all of the controllers were created to extend from the base controller located at protected/components/Controller.php. If we take a peek into this file, we see that there is a layout property explicitly defined. But it does not specify the main layout file. It specifies "column1" as the default layout file for all child classes. You may have already noticed that when the new application was created, there were a few layout files generated for us as well, all in the protected/ views/layouts/ folder: • column1.php • column2.php • main.php So, unless this is being explicitly overridden in a child class, our controllers are defining column1.php as the primary layout file, not main.php. Iteration 8: Making it Pretty- Design, Layout, Themes, and Internationalization(i18n) [ 268 ] So, why did we spend all that time going through main.php, you ask? Well, it turns out that the column1.php layout file is itself decorated by the main.php layout file. So, not only can normal view files be decorated by layout files, but layout files themselves can be decorated by other layout files, forming a hierarchy of nested layout files. This allows for great flexibility in design and also greatly minimizes the need for any repeated markup in view files. Let's take a closer look at column1.php to see how this is achieved. The contents of that file are as follows: beginContent('/layouts/main'); ?>

endContent(); ?> Here we see the use of a couple of methods we have not seen before. The use of the base controller methods beginContent() and endContent() are being used to decorate the enclosed content with the specified view. The view being specified here is our main layout page 'layouts/main'. The beginContent() method actually makes use of the built-in Yii widget, CContentDecorator, whose primary purpose is to allow for nested layouts. So, whatever content is between the calls to beginContent() and endContent() will be decorated with the view specified in the call to beginContent(). If nothing is specified, it will use the default layout specified either at the controller level, or if not specified at the controller level, at the application level. The rest works just as a normal layout file. All of the markup in the specific view file will be contained in the variable $content when this column1.php layout file is rendered, and then the other markup contained in this layout file will be contained again in the variable $content made available to the final rendering of the main parent layout file, main.php. Let's walk through an example. If we take the rendering of the login view as an example, i.e. the following code in the SiteController::actionLogin() method: $this->render('login'); Behind the scenes, the following steps are taken: 1. Render all of the content in the specific view file /protected/views/site/ login.php and make that content available via the variable $content to the layout file specified in the controller, which in this case is column1.php. Chapter 11 [ 269 ] 2. As column1.php is itself being decorated by the layout main.php, the content between the beingContent() and endContent() calls is again rendered and made available to the main.php file, also again via the $content variable 3. The layout file main.php is rendered and returned to the user, incorporating both the content from the specific view file for the login page, as well as the nested layout file, column1.php. Another layout file that was autogenerated for us and being used in the application is column2.php. You probably won't be surprised to discover that this file lays out a two-column design. We can see this used in the project pages, where we have a little sub-menu Operations widget display along the right hand side. The contents of this layout are as follows, and we can see the same approach is being used to achieve the nested layout: beginContent('/layouts/main'); ?>

beginWidget('zii.widgets.CPortlet', array( 'title'=>'Operations', )); $this->widget('zii.widgets.CMenu', array( 'items'=>$this->menu, 'htmlOptions'=>array('class'=>'operations'), )); $this->endWidget(); ?>

endContent(); ?> Iteration 8: Making it Pretty- Design, Layout, Themes, and Internationalization(i18n) [ 270 ] Creating themes Themes provide a systematic way of customizing the design layout of a web application. One of the many benefits of an MVC architecture is the separation of the presentation tier from both the rest of the back-end stuff. Themes make great use of this separation by allowing you to easily and dramatically change the overall look and feel of a web application during runtime. Yii allows for an extremely easy application of themes to provide great flexibility in your web application design. Building themes in Yii In Yii, each theme is represented as a folder consisting of view files, layout files, and relevant resource files such as images, CSS files, JavaScript files, and so on. The name of a theme is the same as its folder name. By default, all themes reside under the same folder WebRoot/themes. Of course, as is the case with all other application settings, this default folder can be configured to be a different one. To do so, simply alter the basePath and the baseUrl properties of the themeManager application component. Contents under a theme folder should be organized in the same way as those under the application base path. For example, all view files must be located under views/, layout view files under views/layouts/, and system view files under views/ system/. For example, if we have created a new theme, called custom, and we want to replace the update view of our ProjectController with a new view under this theme, we need to create a new update.php view file and save it in our application project as themes/custom/views/project/update.php. Creating a Yii theme Let's take this for a spin to give our TrackStar application a little facelift. We need to name our new theme and create a folder under the Webroot/themes folder with this same name. We'll exercise our extreme creativity and call our new theme, new. Create a new folder to hold this new theme located at Webroot/themes/new. Also under this newly created folder, create two other new folders called css/ and views/. The former is not required by the theming system, but helps us keep our CSS organized. The latter is required if we are going to make any alterations to our default view files, which we are. As we are going to change the main.php layout file just a little, we need yet another folder under this newly created views/ folder called layouts/ (remember the folder structure needs to mirror that in the default Webroot/protected/views/ folder). Chapter 11 [ 271 ] Now let's make some changes. As our view file markup is already referencing CSS class and ID names currently defined in the Webroot/css/main.css file, the fastest path to a new face on the application is to use this as a starting point, and make changes to it as needed to implement a new design. Of course, this is not a requirement, as we could re-create every single view file of our application in the new theme. However, to keep things simple, we'll create our new theme by making a few changes to the main.css file that was auto-generated for us when we created the application, as well as the primary layout file, main.php. To begin with, let's make a copy of these two files and place them in our new theme folder. Copy Webroot/css/main.css to Webroot/themes/new/css/main.css and also copy Webroot/protected/views/layouts/main.php to Webroot/themes/ new/views/layouts/main.php. Now, open the newly copied version of the main.css file remove the contents and then add all of the following: body { margin: 0; padding: 0; color: #555; font: normal 10pt Arial,Helvetica,sans-serif; background: #d6d6d6 url(background.gif) repeat-y center top; } #page { margin-bottom: 20px; background: white; border: 1px solid #898989; border-top:none; border-bottom:none; } #header { margin: 0; padding: 0; height:100px; background:white url(header.jpg) no-repeat left top; border-bottom: 1px solid #898989; } #content { padding: 20px; } #sidebar Iteration 8: Making it Pretty- Design, Layout, Themes, and Internationalization(i18n) [ 272 ] { padding: 20px 20px 20px 0; } #footer { padding: 10px; margin: 10px 20px; font-size: 0.8em; text-align: center; border-top: 1px solid #C9E0ED; } #logo { padding: 10px 20px; font-size: 200%; /* HIDES LOGO TEXT */ text-indent:-5000px; } #mainmenu { background:white url(bg2.gif) repeat-x left top; border-top:1px solid #CCC; border-bottom: 1px solid #7d7d7d; } #mainmenu ul { padding:6px 20px 5px 20px; margin:0px; } #mainmenu ul li { display: inline; } #mainmenu ul li a { color:#333; background-color:transparent; font-size:12px; font-weight:bold; text-decoration:none; padding:5px 8px; } #mainmenu ul li a:hover, #mainmenu ul li a.active { color: #d11e1e; Chapter 11 [ 273 ] background-color:#ccc; text-decoration:none; } div.flash-error, div.flash-notice, div.flash-success { padding:.8em; margin-bottom:1em; border:2px solid #ddd; } div.flash-error { background:#FBE3E4; color:#8a1f11; border-color:#FBC2C4; } div.flash-notice { background:#FFF6BF; color:#514721; border-color:#FFD324; } div.flash-success { background:#E6EFC2; color:#264409; border-color:#C6D880; } div.flash-error a { color:#8a1f11; } div.flash-notice a { color:#514721; } div.flash-success a { color:#264409; } div.form .rememberMe label { display: inline; } div.view { Iteration 8: Making it Pretty- Design, Layout, Themes, and Internationalization(i18n) [ 274 ] padding: 10px; margin: 10px 0; border: 1px solid #C9E0ED; } div.breadcrumbs { font-size: 0.9em; padding: 10px 20px; } div.breadcrumbs span { font-weight: bold; } div.search-form { padding: 10px; margin: 10px 0; background: #eee; } .portlet { } .portlet-decoration { padding: 3px 8px; background:white url(bg2.gif) repeat-x left top; } .portlet-title { font-size: 12px; font-weight: bold; padding: 0; margin: 0; color: #fff; } .portlet-content { font-size:0.9em; margin: 0 0 15px 0; padding: 5px 8px; background:#ccc; } .operations li a { Chapter 11 [ 275 ] font: bold 12px Arial; color: #d11e1e; display: block; padding: 2px 0 2px 8px; line-height: 15px; text-decoration: none; } .portlet-content ul { list-style-image:none; list-style-position:outside; list-style-type:none; margin: 0; padding: 0; } .portlet-content li { padding: 2px 0 4px 0px; } .operations { list-style-type: none; margin: 0; padding: 0; } .operations li { padding-bottom: 2px; } .operations li a { font: bold 12px Arial; color: #0066A4; display: block; padding: 2px 0 2px 8px; line-height: 15px; text-decoration: none; } .operations li a:visited { color: #d11e1e; } .operations li a:hover { background: #fff; } Iteration 8: Making it Pretty- Design, Layout, Themes, and Internationalization(i18n) [ 276 ] You may have noticed that some of these changes are referencing image files that do not yet exist in our project. We have added a background.gif image reference in the body declaration, a new bg2.gif image referenced in the #mainmenu ID declaration and a new header.jpg image in the #header ID declaration. These can be viewed, downloaded and used by viewing the site online or accessing the images directly from http://www.yippyii.com/trackstar/themes/new/css/background.gif, http://www.yippyii.com/trackstar/themes/new/css/bg2.gif, and http://www.yippyii.com/trackstar/themes/new/css/header.jpg. We need to place these new images into the same CSS folder we are using for this theme, namely Webroot/themes/new/css/. After these changes are in place, we need to make a couple of small adjustments to our main.php layout file in this new theme. For one, we need to alter the markup in the element to properly reference our new main.css file. Currently the main.css file is being pulled in via this line: This is referencing the application request baseUrl property to construct the relative path to the CSS file. However, we want to use our new main.css file located in our new theme. For this, we can lean on the theme manager application component, defined by default to use the Yii built-in CThemeManager.php class. We access the theme manager in the same way as we access other application components. So, rather than use the request base URL, we should use the one defined by the theme manager, which knows what theme the application is using at any given time. So, we need to alter the above line in /themes/new/views/layouts/main.php as follows: Once we configure our application to use our new theme (something we have not yet done), this baseUrl will resolve to a relative path to where our theme folder resides. The other small change we need to make is to remove the display of the application title from the header. As we altered our CSS to use a new image file to provide our header and logo information, we don't need to display the application name in this section. So, again in /themes/new/views/layouts/main.php, we simply need to change this:

name); ?>

Chapter 11 [ 277 ] To the following:

We have put in a comment to remind us where our header image is defined. One final change we need to make is to the other two layout files used in the application that we are not copying over to our new theme folder, namely protected/ views/layouts/column1.php and protected/views/layouts/column2.php. As previously discussed in the section on nesting layouts, these two layout files also use the main layout file via explicit calls to the beginContent() and endContent(). These files were auto-generated by the Gii code generation tool, and are explicitly referencing the main layout file in protected/views/layouts/ folder. We need to change the input specified to the beginContent() method so that, if available, our new theme layout will be used. Open both the column1.php and column2.php files and change the following line of code: $this->beginContent('application.views.layouts.main'); To be the following: $this->beginContent('/layouts/main'); Now, once we configure the application to use our new theme, it will first look for a main.php layout in the themes folder and use that file. Configuring the application to use a theme Okay, with our new theme now created and in place, we need to tell the application itself to use it. Doing so is easy. We just alter the main application's theme property setting by changing the main application configuration file. By now, we are old pros at doing this. Simply add the following name=>value pair to the returned array in the /protected/config/main.php file: 'theme'=>'new', Iteration 8: Making it Pretty- Design, Layout, Themes, and Internationalization(i18n) [ 278 ] Once this is saved, our application is now using our newly created theme, new, and our application has a brand new face. Taking a look at the login page, which is also our default home page if not logged-in, we now see what is depicted in the following figure: This, of course is not a huge change. We have kept the changes fairly minimal, but it does illustrate the process of creating a new theme. The application will first look for view files in this new theme and use them if they exists, otherwise, it will pull them from the default location. You can see how easy it is to give the application a new look and feel. You could create a new theme for each season, or maybe based on your different moods and then change the application to fit the season or mood quickly and easily as desired. Translating the site to other languages Before we leave this iteration, we are going to talk about internationalization (i18n) and localization (L10n) in Yii. Internationalization refers to the process of designing software applications in such a manner that it can be adapted to various languages without having to make underlying engineering changes. Localization refers to the process of adapting internationalized software applications for a specific geographic location or language by adding locale-dependent formatting and translating text. Yii provides support for these in the following ways: Chapter 11 [ 279 ] • It provides the locale data for nearly every language and region • It provides services to assist in the translation of text message and file • It provides locale-dependent date and time formatting • It provides locale-dependent number formatting Defining locale and language Locale refers to a set of parameters that define the user's language, country, and any other user interface preferences that may be relevant to a user's location. It is typically identified by a composite ID consisting of a language identifier and a region identifier. For example, a locale ID of en_US stands for the English language and the region of the United States. For consistency, all locale IDs in Yii are standardized to the format of either LanguageID or LanguageID_RegionID in lower case (for example, en or en_us). In Yii, locale data is represented as an instance of the CLocale class, or a child class thereof. It provides locale-specific information including currency and numeric symbols; currency, number, date, and time formats; date-related names like months, days of week, and so on. Given a locale ID, one can get the corresponding CLocal instance by either using the static method CLocal::getInstance($localeID) or using the application. The following example code creates a new instance based on the en_us local identifier using the application component: Yii::app()->getLocale('en_us'); Yii comes with locale data for nearly every language and region. The data comes from the Common Locale Data Repository (CLDR) (http://cldr.unicode.org/) and is stored in files that are named according to their respective locale id in the Yii Framework folder framework/i18n/data/. So, in the above example of creating a new CLocale instance, the data used to populate the attributes came from the file framework/i18n/data/en_us.php. If you look under this folder, you will see data files for a great many languages and regions. So, going back to our example, if we wanted to get, say, the names of the months in English specific to the US region, we could execute the following code: $locale = Yii::app()->getLocale('en_us'); print_r($locale->monthNames); Which would produce the following: Array ( [1] => January [2] => February [3] => March [4] => April [5] => May [6] => June [7] => July [8] => August [9] => September [10] => October [11] => November [12] => December ) Iteration 8: Making it Pretty- Design, Layout, Themes, and Internationalization(i18n) [ 280 ] Where as if we wanted, say, the same month names for the Italian language, we could do the same, but create a different CLocale instance: $locale = Yii::app()->getLocale('it'); print_r($locale->monthNames); Which would produce the following: Array ( [1] => gennaio [2] => febbraio [3] => marzo [4] => aprile [5] => maggio [6] => giugno [7] => luglio [8] => agosto [9] => settembre [10] => ottobre [11] => novembre [12] => dicembre ) The first instance is based on the data file framework/i18n/data/en_us.php and the latter on framework/i18n/data/it.php. If desired, the application's localeDataPath property can be configured in order to specify a custom folder in which to add your custom locale data files. Performing language translation Perhaps the most desired feature of i18n is language translation. As mentioned previously, Yii provides both message translation and view translation. The former translates a single text message to a desired language, and the latter translates an entire file to the desired language. A translation request consists of the object to be translated (either a string of text or a file), the source language that the object is in and the target language to which the object is to be translated. A Yii application makes a distinction between its target language and its source language. The target language is the language (or locale) that we are targeting for the user, where the source language refers to the language in which the application files are written. So far, our TrackStar application has been written in English and also targeted to English language users. So our target and source languages thus far have been the same. The internationalization features of Yii, which include translation, are applicable only when these two languages are different. Performing message translation Message translation is performed by calling the application method: t(string $category, string $message, array $params=array ( ), string $source=NULL, string $language=NULL) This method translates the message from the source language to the target language. When translating a message, the category must be specified to allow a message to be translated differently under different categories (contexts). The category yii is reserved for messages used by the Yii Framework core code. Chapter 11 [ 281 ] Messages can also contain parameter placeholders which will be replaced with the actual parameter values upon calling Yii::t(). The following example depicts the translation of an error message. This message translation request would replace the {errorCode} placeholder in the original message with the actual $errorCode value: Yii::t('category', 'The error: "{errorCode}" was encountered during the last request.', array('{errorCode}'=>$errorCode)); The translated messages are stored in a repository called message source. A message source is represented as an instance of CMessageSource or its child class. When Yii::t() is invoked, it will look for the message in the message source and return its translated version if it is found. Yii comes with the following types of message sources: • CPhpMessageSource: This is the default message source. The message translations are stored as key-value pairs in a PHP array. The original message is the key and the translated message is the value. Each array represents the translations for a particular category of messages and is stored in a separate PHP script file whose name is the category name. The PHP translation files for the same language are stored under the same folder named as the locale ID. All these folders are located under the folder specified by basePath. • CGettextMessageSource: The message translations are stored as GNU Gettext files. • CDbMessageSource: The message translations are stored in database tables. A message source is loaded as an application component. Yii pre-declares an application component named messages to store messages that are used in a user application. By default, the type of this message source is CPhpMessageSource and the base path for storing the PHP translation files is protected/messages. An example will go a long way to helping bring all of this together. Let's translate the form field labels on our Login form into a fictitious language we'll call Reversish. Reversish is written by taking an English word or phrase and writing it in reverse. So, here are the Reversish translations of our login form field labels: English Reversish Username Emanresu Password Drowssap Remember me next time Emit txen em rebmemer Iteration 8: Making it Pretty- Design, Layout, Themes, and Internationalization(i18n) [ 282 ] We'll use the default CPhpMessageSource implementation to house our message translations. So, the first thing we need to do is create a PHP file containing our translations. We'll make the locale ID be 'rev' and we'll just call the category 'default' for now. So, we need to create a new file under the messages base folder that follows the format /localeID/CategoryName.php. So, for this example, we need to create a new file located at /protected/messages/rev/default.php, and then add the following translation array: 'Emanresu', 'Password' => 'Drowssap', 'Remember me next time' => 'Emit txen em rebmemer', ); The next thing we need to do is to set the application target language to be Reversish. We could do this in the application configuration file, so that it would impact the entire site. However, as we only have translations for our login form, we'll just set it down in the SiteController::actionLogin() method, so that it will only apply when rendering the login form for now. So, open that file and set the application target language right at the beginning of that method: public function actionLogin() { Yii::app()->language = 'rev'; Now, the last thing we need to do is to make our calls to Yii::t() so that these form field labels are sent through the translation. These form field labels are defined in the LoginForm:: attributeLabels() method. Replace that entire method with the following: /** * Declares attribute labels. */ public function attributeLabels() { return array( 'rememberMe'=>Yii::t('default','Remember me next time'), 'username'=>Yii::t('default', 'Username'), 'password'=>Yii::t('default', 'Password'), ); } Chapter 11 [ 283 ] Now if we visit our login form again, we see a new Reversish version as depicted in the following screenshot: Performing file translation Yii also provides the ability to use different files based on the target locale ID setting of the application. File translation is accomplished by calling the application method CApplication::findLocalizedFile(). This method takes in the path to a file and this method will look for a file with the same name, but under a directory named the same as the target locale ID specified either as explicit input to the method, or what is specified in the application configuration. Let's try this out. All we really need to do is to create the appropriate translation file. We'll stick with translating the login form. So, create a new view file /protected/ views/site/rev/login.php and add the following contents that have already been translated to Reversish: pageTitle='Nigol'; $this->breadcrumbs=array( 'Nigol', ); ?>

Nigol

Slaitnederc nigol ruoy htiw mrof gniwollof eht tuo llif esaelp:

beginWidget('CActiveForm', array( 'id'=>'login-form', Iteration 8: Making it Pretty- Design, Layout, Themes, and Internationalization(i18n) [ 284 ] 'enableAjaxValidation'=>true, )); ?>

Deriuqer era * htiw sdleif.

labelEx($model,'username'); ?> textField($model,'username'); ?> error($model,'username'); ?>

labelEx($model,'password'); ?> passwordField($model,'password'); ?> error($model,'password'); ?>

nimda\nimda ro omed\omed htiw nigol yam uoy :tnih

checkBox($model,'rememberMe'); ?> label($model,'rememberMe'); ?> error($model,'rememberMe'); ?>

endWidget(); ?>

We are already setting the target language for the application within the SiteController::actionLogin() method, and the call to get the localized file will be taken care of for us behind the scenes when calling render('login'). So, with this in place, our login form now looks as shown in the following screenshot: Chapter 11 [ 285 ] Summary In this iteration, we have seen how a Yii application allows you to quickly and easily polish up the design. We were introduced to the concept of layout files and walked through how to use these in an application to layout content and design that needs to be implemented in a similar manner across many different web pages. This also introduced us to the CMenu and CBreadcrumbs built-in widgets that provide easy to use and implement UI navigational constructs on each page. We then introduced the idea of a theme within Web applications and how they are specifically implementing within a Yii application. We saw that themes allow you to easily put a new face on an existing Web application and allow you to re-design your application without re-building any of the functionality or backend Finally, we looked at changing the face of the application through the lens of i18n and language translation. We learned how to set the target locale of the application to enable localization settings and language translations. We have made a few references in this and past chapters to modules, but have yet to dive into what exactly these are within a Yii application. That is going to be the focus of the next chapter. Iteration 9: Modules - Adding Administration So far we have added a lot of functionality to our TrackStar application. If you recall back in Chapter 8, we introduced user access controls to restrict certain functionality based on a user role hierarchy. This was helpful in restricting access to some of the administrative functions on a per-project basis. For example, within a specific project, you may not want to allow all members of the team access to delete the project. We used a role based access control implementation to assign users to specific roles within a project, and then allowed/restricted access to functionality based on those roles. However, what we have not yet addressed are the administrative needs of the application as a whole. Web applications such as TrackStar often require the ability for very special users to have full access to administer everything. One example is the ability to manage all the CRUD operations for every single user of the system, regardless of the project. A system administrator of our application should be able to log in and remove or update any user, any project, any issues, moderate all comments, and so on. Also, it is often the case that we build extra features that apply to the whole application, like the ability to leave site-wide system messages to all users, manage e-mail campaigns, turn on/off certain application features, manage the roles and permissions hierarchy itself, change the site theme, and so on. As the functionality exposed to the administrator can differ greatly from the functionality exposed to normal users, it is often a good idea to keep these features separate from the rest of the application. We will be accomplishing this separation by building all of our administrative functionality in what is called a module in Yii. Iteration 9: Modules - Adding Administration [ 288 ] Iteration planning In this iteration, we will focus on the following granular development tasks: • Creating a new module to house administrative functionality • Creating the ability for administrators to add system-wide messages for application users to view on the projects listing page • Applying a new theme to the module • Creating a new table to hold the system message data • Generating all CRUD functionality for our system messages • Limiting access to all functionality within the new module only to admin users • Displaying new system messages on the projects listing page Modules A module is similar to an entire mini-application contained within a larger application. It has a similar structure, containing models, views, controllers, and other supporting components. However, modules cannot be deployed themselves as stand-alone applications, they must reside within an application. Modules are useful in helping architect your application in a modular fashion. Large applications can often be segmented into discrete application features that could be separately built using modules. Site features such as adding a user forum, user blogs, or site-administrator functionality are some example candidates that could be segmented from the main site features allowing them to be developed separately and easily reused in future projects. We are going to use a module to create a distinct place in our application to house our administrative functionality. Creating a module Creating a new module is a snap using our old friend, the Gii code generation tool. With our URL changes in place, the tool is now accessible via http://localhost/ trackstar/gii. Navigate there, and choose the Module Generator option from the left menu. You will be presented with the following screen: Chapter 12 [ 289 ] We need to provide a unique name for the module. As we are creating an admin module, we'll be super creative and give it the name admin. So type this in for the Module ID field, and click on the Preview button. As the following screenshot shows, it will present you with all of the files it intends to generate, allowing you to preview each of these files prior to creating them: Iteration 9: Modules - Adding Administration [ 290 ] Then click the Generate button to have it create all of these files. You will need to ensure that your /protected folder is writable by the web server process for it to automatically create the required folders and files. The following screenshot shows a successful module generation: Let's take a closer look at what the module generator created for us. A module in Yii is organized as a folder, the name of which is the same as the unique name of the module. By default, all module folders reside under protected/modules. The structure of each module folder is very similar to that of our main application. What this command has done for us is to create the skeleton folder structure for the admin module. As this was our first module, the top-level folder protected/modules was created, and then an admin/ folder underneath. The following shows all of the folders and files that were created when we executed the module command: Name of folder Use/contents admin/ AdminModule.php the module class file components/ containing reusable user components controllers/ containing controller class files Chapter 12 [ 291 ] Name of folder Use/contents DefaultController. php the default controller class file messages/ stores message translations specific to the module models/ containing model class files views/ containing controller view and layout files default/ containing view files for DefaultController index.php the index view file layouts/ containing layout view files A module must have a module class that extends either directly or from a child of CWebModule. The module class name is created by combining the module ID (that is, the name we supplied when we created the module, admin) and the string Module. The first letter of the module ID is also capitalized. So, in our case, our admin module class file is named AdminModule.php. The module class serves as the central place for storing information shared by the module code. For example, we can use the params property of CWebModule to store module specific parameters, and use its components property to share application components at the module level. This module class serves a similar role to the module as the application class does to the entire application. So CWebModule is to our module what CWebApplication is to our application. Using a module Just as the successful creation message indicated, before we can use our new module we need to configure the modules property of the main application to include it for use. We did this before when we added the gii module to our application, which allowed us to access the Gii code generation tool. We make this change in the main configuration file, protected/config/main.php. The following highlighted code indicates the required change: 'modules'=>array( 'gii'=>array( 'class'=>'system.gii.GiiModule', 'password'=>'iamadmin', ), 'admin', ), Iteration 9: Modules - Adding Administration [ 292 ] After saving this change, our new admin module is wired-up for use. We can take a look at the simple index page that was created for us by visiting http://localhost/ trackstar/admin/default/index. The request routing structure to access pages in our module is similar to that for our main application pages, except that we need to include the moduleID in the route as well. So our routes will be of the general form / moduleID/controllerID/actionID. Our URL request /admin/default/index is requesting the admin module's default controller's index method. When we visit this page, we see something similar to the following screenshot: Theming a module We immediately notice that there doesn't seem to be any layout applied to this view. One might guess that maybe the controller that is rendering this view is calling renderPartial() rather than render(). However, upon inspection of our default admin controller file, /protected/modules/admin/controllers/ DefaultController.php, we see that it is, in fact, using the render() method. Thus, we expect a layout file (if one exists) to be applied. The issue is that almost everything is separate in a module, including the default path for layout files. The default layout path for web modules is /protected/ modules/[moduleID]/views/layouts, where moduleID in our case is admin. We can see that there are no files under this folder, so there is no default layout to be applied. There is slightly more to the story in our case, however. In the previous iteration, we implemented a new theme, called new. We can also manage all of our module view files, including the layout view files, within this theme as well. If we were to do that, we need to add to our theme folder structure to accommodate our new module. The folder structure is very much as expected. It is of a general form: / themes/[themeName]/views/[moduleID]/layouts/ for layout files and /themes/ [themeName]/views/[moduleID]/[controllerID]/ for controller view files. To clarify, let's walk through Yii's decision-making process when it is trying to decide what view files to use for our new admin module. Here is what is happening when $this->render('index') is issued in the DefaultController.php file within our admin module: Chapter 12 [ 293 ] 1. As render() is being called, as opposed to renderPartial(), it is going to attempt to decorate the specified index.php view file with a layout file. Our application is currently configured to use a theme called new, so it is going to look for layout files under this theme folder. Our new module's DefaultController class extends our application component Controller. php, which has column1 specified as its $layout property. This property is not overridden so it is also the layout file for DefaultController. Finally, as this is all happening within the admin module, Yii first looks for the following layout file: /themes/new/views/admin/layouts/column1.php. Notice the inclusion of the moduleID in this folder structure. 2. This file does not exist, so it reverts to looking in the default location for the module. As previously mentioned, the default layout folder is specific to each module. So, in this case it will attempt to locate the following layout file: /protected/modules/admin/views/layouts/column1.php. 3. This file also does not exist, so it will be unable to apply a layout. It will now simply attempt render the specified index.php view file without a layout. However, again as we have specified the specific "new" theme for the application, it first looks for the following view file: /themes/new/ views/admin/default/index.php. 4. This file also does not exist, so it will look again in the default location for this controller (DefaultController.php) within this module (AdminModule), namely: /protected/modules/admin/views/default/index.php. This explains why the page http://localhost/trackstar/admin/default/index is rendered without any layout. To keep things completely separate and simple for now, let us manage our view files in the default location for our module, rather than under the new theme. Also, let's apply to our admin module the same design as our original application had, that is, how the application looked before we applied the new theme. This way our admin pages will have a different look from our normal application pages, which will help remind us that we are in the special admin section, but we won't have to spend any time coming up with a new design. Applying a theme First, let's set a default layout value for our module. We set our module-wide configuration settings in the init() method within our module class, /protected/ modules/AdminModule.php. So open that file and add the following code in bold: class AdminModule extends CWebModule { public function init() { // this method is called when the module is being created Iteration 9: Modules - Adding Administration [ 294 ] // you may place code here to customize the module or the application // import the module-level models and components $this->setImport(array( 'admin.models.*', 'admin.components.*', )); $this->layout = 'main'; } ... This way, if we have not specified a layout file at a more granular level, like in a controller class, all of the module views will be decorated by the layout file main.php located in the default layout folder for our module, namely /protected/modules/ admin/views/layouts/. Now, of course, we need to create this file. Make a copy of the two layout files from the main application: /protected/views/layouts/main.php and /protected/ views/layouts/column1.php, and place them both in the /protected/modules/ admin/views/layouts/ folder. After you have copied those over, we need to make a few changes to both of them. First let's alter column1.php. Remove the explicit reference to /layouts/main in the call to beginContent() as follows: beginContent(); ?>

endContent(); ?> Not specifying an input file when calling beginContent() will result in it using the default layout for our module, which we just set to be our newly copied main.php file. Now let's make a few changes to our main.php layout file. We are going to add Admin Console to our application header text to underscore that we are in a separate part of the application. We will also alter our menu items to have a link to the admin home page, as well as a link to go back to the main site. We can remove the About and Contact links from this menu, as we don't need to repeat those options in our admin section. The changes to the file are highlighted below: Chapter 12 [ 295 ] ...

name) . " Ad- min Console"; ?>

widget('zii.widgets.CMenu',array( 'items'=>array( array('label'=>'Back To Main Site', 'url'=>array('/proj- ect')), array('label'=>'Admin', 'url'=>array('/admin/default/in- dex')), array('label'=>'Login', 'url'=>array('/site/login'), 'visible'=>Yii::app()->user->isGuest), array('label'=>'Logout ('.Yii::app()->user->name.')', 'url'=>array('/site/logout'), 'visible'=>!Yii::app()->user->isGuest) ), )); ?>

... We can leave the rest of the file unchanged. Now if we visit our admin module page, we see something similar to the following screenshot: If we click on the Back To Main Site link, we see that we are taken back to our newly themed version of our main application. Restricting admin access One problem you may have already noticed is that anyone, including guest users, can access our new admin module. We are building this admin module to expose application functionality that should only be accessible to users with administrative access. So, we need to address this issue. Iteration 9: Modules - Adding Administration [ 296 ] Luckily, we have already implemented an RBAC access model in our application back in Chapter 8. All we need to do now is extend it to include a new role for administrators and new permissions available to that role. If you recall from chapter 8, we used a Yii shell command to implement our RBAC structure. We need to add to that. So, open up the file containing that shell command, /protected/commands/shell/RbacCommand.php and add the following: //create a general task-level permission for admins $this->_authManager->createTask("adminManagement", "access to the application administration functionality"); //create the site admin role, and add the appropriate permissions $role=$this->_authManager->createRole("admin"); $role->addChild("owner"; $role->addChild("reader"); $role->addChild("member"); $role->addChild("adminManagement"); //ensure we have one admin in the system (force it to be user id #1) $this->_authManager->assign("admin",1); With these changes in place, we have to rerun our command to update the database with these changes. To do so, just fire-up the yiic shell, and execute the rbac command: % cd Webroot/trackstar % protected/yiic shell >> rbac With these changes to our RBAC model in place, we can add an access check to the AdminModule::beforeControllerAction() method so that nothing within the admin module will be executed unless the user has the admin role: public function beforeControllerAction($controller, $action) { if(parent::beforeControllerAction($controller, $action)) { // this method is called before any module controller action is performed // you may place customized code here if( !Yii::app()->authManager->checkAccess("admin", Yii::app()- >user->id) ) { throw new CHttpException(403,Yii::t('yii','You are not au- thorized to perform this action.')); } Chapter 12 [ 297 ] else { return true; } } else return false; } With this in place, if a user who has not been assigned the admin role now attempts to visit any page within the admin module, they will be met with an authorization error page. For example, if you are not logged in and you attempt to visit the admin page, you will be met with the following result: The same holds true for any user that has not been assigned to the admin role. Now we can conditionally add a link to the admin section of the site to our main application menu. This way, users with administrative access won't have to remember a cumbersome URL to navigate to the admin console. As a reminder, our main application menu is located in our application's theme default application layout file /themes/new/views/layouts/main.php. Open that file and add the following highlighted code to the menu section:

widget('zii.widgets.CMenu',array( 'items'=>array( array('label'=>'Projects', 'url'=>array('/project')), array('label'=>'About', 'url'=>array('/site/page', 'view'=>'about')), array('label'=>'Contact', 'url'=>array('/site/contact')), array('label'=>'Admin', 'url'=>array('/admin/default/index'), 'visible'=>Yii::app()->authManager->checkAccess("admin", Yii::app()- >user->id)), array('label'=>'Login', 'url'=>array('/site/login'), Iteration 9: Modules - Adding Administration [ 298 ] 'visible'=>Yii::app()->user->isGuest), array('label'=>'Logout ('.Yii::app()->user->name.')', 'url'=>array('/site/logout'), 'visible'=>!Yii::app()->user->isGuest) ), )); ?>

Now, upon logging in to the application as a user with admin access, we will see a new link in our top navigation that will take us to our newly added admin section of the site. Adding a system-wide message As a module can really be thought of as a mini-application itself, adding functionality to a module is really the same process as adding functionality to the main application. Let's add some new functionality just for administrators; the ability to manage system-wide messages displayed to users when they first log into the application. Creating the database table As is often the case with brand new functionality, we need a place to house our data. We need to create a new table to store our system-wide messages. For our purposes, we can keep this simple. Here is the definition for our table: CREATE TABLE `tbl_sys_message` ( `id` INTEGER NOT NULL PRIMARY KEY AUTO_INCREMENT, `message` TEXT NOT NULL, `create_time` DATETIME, `create_user_id` INTEGER, `update_time` DATETIME, `update_user_id` INTEGER ) Chapter 12 [ 299 ] Create this new table in both the main trackstar_dev and our trackstar_test databases. Creating our model and CRUD scaffolding With the table in place, our next step is to generate the model class using our favorite tool, the Gii code generator. We'll first use the Model Generator option to create the model class, and then the Crud Generator to create our basic scaffolding to quickly interact with this model. Go ahead and navigate to the Gii tool form for creating a new model. This time, as we are doing this within the context of a module, we need to explicitly specify the model path. Fill out the form with the values depicted as shown in the following screenshot (though, of course, your Code Template path value should be specific to your local setup): Iteration 9: Modules - Adding Administration [ 300 ] Now we can create the CRUD scaffolding in the same way. Again, the only real difference between what we have done previously and what we are doing now is our specification that the location of the model class is in the admin module. After choosing the Crud Generator option from the Gii tool, fill out the Model Class and Controller ID form fields as shown in the following screenshot: This alerts the tool to the fact that our model class is under the admin module and that our controller class, as well as all other files related to this code generation should be placed within the admin module as well. Complete the creation by first clicking on the Preview button, and then Generate. The following is a list of all of the files that are created by this action: Chapter 12 [ 301 ] Adding a link to our new functionality Let's add a new menu item within the main admin navigation that links to our newly created message functionality. Open the file that contains our main menu navigation for our module, /protected/modules/admin/views/layouts/main.php, and add the following array item to the menu widget: array('label'=>'System Messages', 'url'=>array('/admin/sysMessage/ index')), As the auto-created controller and view files for our new system message functionality were created to use a 2-column layout file, we can do one of two things. We can alter the controller class to use our existing single column layout file, or we can add a 2 column layout file to our module layout files. The latter is going to be slightly easier and will also look better, as all of the view files are created to have their sub-menu items (that is, the links to all the CRUD functionality) display in a second right-hand column. Here is all we have to do: 1. Copy the 2 column layout from our main application to our module: That is, copy /protected/views/layouts/column2.php to /protected/modules/ admin/views/layouts/column2.php. 2. Remove /layouts/main as input to the beginContent() method call on the first line in the newly copied column2.php file. 3. Alter the SysMessage model class to extend TrackstarActiveRecord (If you recall, this adds the code to automatically update our create_time/ user and update_time/user properties. Alter the SysMessageController controller class to use the new column2.php layout file from within the module folder and not the one from the main application. The autogenerated code has specified $layout='application.views.layouts.column2', but we need this to be simply $layout='column2'. 4. As we are extending TrackstarActiveRecord, we can remove the unnecessary fields from our autogenerated sys messages creation form and remove their associated rules from the model class. Remove the following two rules from the SysMessage::rules() method: array('create_user, update_user', 'numerical', 'integerOnly'=>true), and array('create_time, update_time', 'safe'). You don't absolutely have to do this last step, but it is good to get in to the habit of only specifying rules for those fields that the user can input. Iteration 9: Modules - Adding Administration [ 302 ] One last change we should make is to update our simple access rules to reflect the requirement that only users in the admin role can access our action methods. This is mostly for illustrative purposes as we already took care of the access using our RBAC model approach in the AdminModule::beforeControlerAction method itself. We could actually just remove the accessRules entirely. However, let's just update them to reflect the requirement so you can see how that would work using the access rule approach. In the SysMessageController::accessRules() method, change the entire contents to the following: public function accessRules() { return array( array('allow', // allow only users in the 'admin' role access to our actions 'actions'=>array('index','view', 'create', 'update', 'admin', 'delete'), 'roles'=>array('admin'), ), array('deny', // deny all users 'users'=>array('*'), ), ); } Okay, with all of this in place, if we now access our new message input form by visiting http://localhost/trackstar/admin/sysMessage/create, we are presented with something similar to the following screenshot: Chapter 12 [ 303 ] Fill out this form with the message Hello Users! This is your admin speaking... and then click Submit. The application will redirect you to the details listing page for this newly created message as shown in the following screenshot: Displaying the message to users Now that we have a message in our system, let's display it to the user on the application's home page. Importing the new model class for application-wide access In order to access the newly created model from anywhere in our application, we need to import it as a part of the application configuration. Alter protected/ config/main.php to include the new admin module models folder: // autoloading model and component classes 'import'=>array( 'application.models.*', 'application.components.*', 'application.modules.admin.models.*', ), Iteration 9: Modules - Adding Administration [ 304 ] Selecting the most recently updated message We'll restrict the display to just one message, and we'll choose the most recently updated message, based on the update_time column in the table. As we want to add this to the main projects listing page, we need to alter the ProjectController::act ionIndex() method. Alter that method by adding the following highlighted code: public function actionIndex() { $dataProvider=new CActiveDataProvider('Project'); Yii::app()->clientScript->registerLinkTag( 'alternate', 'application/rss+xml', $this->createUrl('comment/feed')); //get the latest system message to display based on the update_time column $sysMessage = SysMessage::model()->find(array( 'order'=>'t.update_time DESC', )); if($sysMessage != null) $message = $sysMessage->message; else $message = null; $this->render('index',array( 'dataProvider'=>$dataProvider, 'sysMessage'=>$message, )); } Now we need to alter our view file to display this new bit of content. Add the following to views/project/index.php, just above the

Projects

header text:

Chapter 12 [ 305 ] Now when we visit our projects listing page (that is, our application's home page) we can see it display as shown in the following screenshot: Adding a little design tweak Okay. This does what we wanted it to do, but this message does not really stand out very well to the user. Let's change that by adding a little snippet to our main css file (/themes/new/css/main.css): div.sys-message { padding:.8em; margin-bottom:1em; border:3px solid #ddd; background:#9EEFFF; color:#FF330A; border-color:#00849E; } With this in place, our message now really stands out on the page. The following screenshot shows the message with these changes in place: One might argue that this design tweak went a little too far. Users might get a headache if they have to stare at those message colors all day. Rather than toning down the colors, let's use a little JavaScript to fade the message out after five seconds. As we will display the message every time the user visits this home page, it might be nice to prevent them from having to stare at it for too long. Iteration 9: Modules - Adding Administration [ 306 ] We'll make things easy on ourselves and take advantage of the fact that Yii comes shipped with the powerful JavaScript framework jQuery. jQuery is an open source JavaScript library that simplifies the interaction between the HTML Document Object Model (DOM) and JavaScript. It is outside the scope of this book to dive into the details of jQuery, but it is well worth visiting its documentation to become a little acquainted with its features. As Yii comes shipped with jQuery, you can simply register jQuery code in view files and Yii will take care of including the core jQuery library for you. We'll also use the application helper component CClientScript to register our jQuery JavaScript code for us in the resulting web page. It will make sure it is placed in the appropriate place as well as properly tagged and formatted. So, let's alter what we previously added to include a snippet of JavaScript that will fade out the message. Replace what we just added to views/project/index.php with the following:

clientScript->registerScript( 'fadeAndHideEffect', '$(".sys-message").animate({opacity: 1.0}, 5000). fadeOut("slow");' ); endif; ?> Now if we reload our main projects listing page, we see the message fade out after five seconds. For more information on cool jQuery effects you can easily add to your pages, take a look at the JQuery API documentation at: http://api.jquery.com/ category/effects/ Finally, to convince yourself everything is working as expected, you can add another system-wide message. As this newer message will have a more recent update_time property, it will be the one to display on the projects listing page. Chapter 12 [ 307 ] Summary In this iteration, we have introduced the concept of a Yii module and demonstrated its practicality by using one to create an administrative section of the site. We demonstrated how to create a new module, how to apply a theme, how to add application functionality within the module, and even how to take advantage of an existing RBAC model to apply authorization access controls to a functionality within a module. We also demonstrated how to use jQuery to add a dash of UI flare to our application. With the addition of this administrative interface, we now have all of the major pieces of the application in place. Though the application is incredibly simple, we feel it is time to get it ready for production. The next iteration will focus on preparing our application for production deployment. Iteration 10: Production Readiness Even though our application lacks a significant amount of feature functionality, our (albeit imaginary) deadlines are approaching and our (also imaginary) client is getting anxious about getting the application into a production environment. Although it may take some time before our application actually sees the light of day in production it is time to get the application "production ready". In this, our final development iteration, we are going to do just that. Iteration planning In order to achieve the goal of preparing our application for a production environment, we are going to focus on the following granular tasks: • Implement Yii's application logging framework to ensure we are logging information about critical production errors and events • Implement Yii's application error handling framework to ensure we understand how this works differently in a production environment than in a development environment • Implement application data caching to help improve performance Logging Logging is a topic that should arguably have been covered before this late stage in the application development. Informational, warning, and severe error messages are invaluable when it comes to troubleshooting software applications, most certainly those in a production environment being used by real users. Iteration 10: Production Readiness [ 310 ] Yii provides a flexible and extensible logging feature. Messages logged can be classified according to log levels and message categories. Using level and category filters, selected messages can be further routed to different destinations, such as written to files on disc, sent to administrators as e-mails or displayed to browser windows. Message logging Our application has actually been logging many informational messages upon each request the entire time. When the initial application was created, it was configured to be in debug mode and, while in this mode, the Yii Framework itself logs information messages. We can't actually see these messages because, by default, they are being logged to memory. So, they are around only for the lifetime of the request. Whether or not the application is in this debug mode is controlled by the following line in the root index.php file: defined('YII_DEBUG') or define('YII_DEBUG',true); To see what is being logged, let's whip up a quick little action method in our SiteController class to display the messages: public function actionShowLog() { echo "Logged Messages:

"; var_dump(Yii::getLogger()->getLogs()); } If we invoke this action by making the following request at: http://localhost/ trackstar/site/showLog, we see something similar to the following: Chapter 13 [ 311 ] If we comment out our global application debug variable, defined in index.php, and refresh the page, we'll notice that nothing was logged. This is because this system-level debugging information level logging is accomplished by calling Yii::trace, which only logs the message if the application is in this special debug mode. We can log messages using one of two static application methods: • Yii::log($message, $level, $category) • Yii::trace($message, $category) As mentioned, the main difference between these two methods is that Yii::trace logs the message only when the application is in debug mode. Categories and levels When logging a message, we need to specify its category and level. The category is represented by a string in the format of xxx.yyy.zzz, which resembles the path alias. For example, if a message is logged in our application's SiteController class, we may choose to use the category application.controllers.SiteController. The category is there to provide extra context to the message being logged. In addition to specifying the category, when using Yii::log, we can also specify a level for the message. The level can be thought of as the severity of the message. You can define your own levels, but typically they take on one of the following values: • Trace: This level is commonly used for tracing the execution flow of the application during development. • Info: This level is for logging general information, and it is the default level if none is specified. • Profile: This level is to be used with the performance profile feature, which is described below. • Warning: This level is for warning messages. • Error: This is level for fatal error messages. Iteration 10: Production Readiness [ 312 ] Adding a login message log As an example, let's add some logging to our user login method. We'll provide some basic debugging information at the beginning of the method to indicate the method is being executed. We'll then log an informational message upon a successful login as well as a warning message if the login fails. Alter our SiteController::actionLogin() method as follows: /** * Displays the login page */ public function actionLogin() { Yii::app()->language = 'rev'; Yii::trace("The actionLogin() method is being requested", "application.controllers.SiteController"); if(!Yii::app()->user->isGuest) { $this->redirect(Yii::app()->homeUrl); } $model=new LoginForm; // if it is ajax validation request if(isset($_POST['ajax']) && $_POST['ajax']==='login-form') { echo CActiveForm::validate($model); Yii::app()->end(); } // collect user input data if(isset($_POST['LoginForm'])) { $model->attributes=$_POST['LoginForm']; // validate user input and redirect to the previous page if valid if($model->validate() && $model->login()) { Yii::log("Successful login of user: " . Yii::app()->user- >id, "info", "application.controllers.SiteController"); $this->redirect(Yii::app()->user->returnUrl); } Chapter 13 [ 313 ] else { Yii::log("Failed login attempt", "warning", "application. controllers.SiteController"); } } // display the login form //public string findLocalizedFile(string $srcFile, string $srcLanguage=NULL, string $language=NULL) $this->render('login',array('model'=>$model)); } If we now successfully log in (or perform a failed attempt) and visit our page to view the logs, we don't see them (If you commented out the debug mode declaration, make sure you have put the application back in debug mode for this exercise). Again, the reason is that by default, the logging implementation in Yii simply stores the messages in memory. They disappear when the request completes. This is not terribly useful. We need to route them to a more persistent storage area so we can view them outside of the request in which they are generated. Message routing As we mentioned, by default, messages logged using Yii::log or Yii::trace are kept in memory. Typically, these messages are more useful if they are displayed in browser windows, or saved to some persistent storage such as in a file, or in a database or sent as an e-mail. Yii's message routing allows for the log messages to be routed to different destinations. In Yii, message routing is managed by a CLogRouter application component. It allows you to define a list of destinations to which the log messages should be routed. In order to take advantage of this message routing, we need to configure the CLogRouter application component in our protected/config/main.php config file. We do this by setting its routes property with the desired log message destinations. If we open our config file, we see that some configuration information has already been provided (again, courtesy of using the yiic webapp command to initially create our application). The following is already defined in our configuration: 'log'=>array 'class'=>'CLogRouter', 'routes'=>array( Iteration 10: Production Readiness [ 314 ] array( 'class'=>'CFileLogRoute', 'levels'=>'error, warning', ), // uncomment the following to show log messages on web pages /* array( 'class'=>'CWebLogRoute', ), */ ), ), The log application component is configured to use the framework class CLogRouter. You could also certainly create and use a custom child class of this if you have logging requirements not fully met by the base framework implementation, but in our case, this will work just fine. What follows the class definition in the previous configuration is the definition of the routes property. In this case, there is just one route specified. This one is using the Yii Framework message routing class, CFileLogRoute. The CFileLogRoute message routing class uses the filesystem to save the messages. By default, messages are logged in a file under the application runtime folder, /protected/runtime/ application.log. In fact, if you have been following along with us and have your own application, you can take a peek at this file and will see several messages that have been logged by the framework. The levels specification dictates that only messages whose log level is either error or warning will be routed to this file. The part of the configuration in the preceding code that is commented out specifies another route, CWebLogRoute. If used, this will route the message to be displayed on the currently requested web page. The following is a list of message routes currently available in version 1.1 of Yii: • CDbLogRoute: Saves messages in a database table • CEmailLogRoute: Sends messages to specified e-mail addresses • CFileLogRoute: Saves messages in a file under the application runtime folder • CWebLogRoute: Displays messages at the end of the current web page • CProfileLogRoute: Displays profiling messages at the end of the current web page The logging that we added to our SiteController::actionLogin() method used Yii::trace for one message and then used Yii::log for two more. When using Yii::trace, the log level is automatically set to trace. When using the Yii::log we Chapter 13 [ 315 ] specified an info log level if the login was successful and a warning level if the login attempt failed. Let's alter our log routing configuration to write the trace and info level messages to a new, separate file called infoMessages.log in the same folder as our application.log file. Also, let's configure it to write the warning messages to the browser. To do that, we make the following changes to the configuration: 'log'=>array( 'class'=>'CLogRouter', 'routes'=>array( array( 'class'=>'CFileLogRoute', 'levels'=>'error', ), array( 'class'=>'CFileLogRoute', 'levels'=>'info, trace', 'logFile'=>'infoMessages.log', ), array( 'class'=>'CWebLogRoute', 'levels'=>'warning', ), ... Now, after saving these changes, let's try out the different scenarios. First, try a successful login. Doing so will write two messages out to our new /protected/ runtime/infoMessages.log file, one for the trace and then one logging the successful login. After successfully logging in, viewing that file reveals the following (The full listing was truncated to save a few trees): … 2010/04/15 00:31:52 [trace] [application.controllers.SiteController] The actionLogin() method is being requested 2010/04/15 00:31:52 [trace] [system.web.CModule] Loading "user" application component 2010/04/15 00:31:52 [trace] [system.web.CModule] Loading "session" application component 2010/04/15 00:31:52 [trace] [system.web.CModule] Loading "db" application component 2010/04/15 00:31:52 [trace] [system.db.CDbConnection] Opening DB connection … 2010/04/15 00:31:52 [info] [application.controllers.SiteController] Successful login of user: 1 … Iteration 10: Production Readiness [ 316 ] Wow, there is a lot more in there than just our two messages. But our two did show up; they are bolded in the above listing. Now that we are routing all of trace messages to this new file, all of the framework trace messages are showing up here as well. This is actually very informative and helps you get a picture of the lifecycle of a request as it makes its way through the framework. There is a lot going on under the covers. We would obviously turn off this verbose level of logging when moving this application to production. In non-debug mode, we would only see our single info level message. But this level of detail can be very informative when trying to track down bugs and just figure out what the application is doing. It is comforting to know it is here when/if ever needed. Now let's try the failed login attempt scenario. If we now log out and try our login again, but this time specify incorrect credentials to force a failed login, we see our warning level display along the bottom of the returned web page, just as we configured it to do. The following screenshot shows this warning being displayed: When using the CLogRouter message router, the logfiles are stored under the logPath property and the filename is specified by the logFile. Another great feature of this log router is automatic logfile rotation. If the size of the logfile is greater than the value set in the maxFileSize (in kilobytes) property, a rotation is performed, which renames the current logfile by suffixing the filename with '1'. All existing logfiles are moved backwards one place, that is, '.2' to '.3', '.1' to '.2'. The property maxLogFiles can be used to specify how many files are to be kept. Handling errors Properly handling the errors that invariably occur in software applications is of the utmost importance. This, again, is a topic that arguably should have been covered prior to coding our application, rather than at this late stage. Luckily, though, as we have been leaning on tools within the Yii Framework to autogenerate much of our core application skeleton, our application is already taking advantage of some of Yii's error handling features. Chapter 13 [ 317 ] Yii provides a complete error handling framework based on PHP 5 exceptions, a built-in mechanism for handling program failures through centralized points. When the main Yii application component is created to handle an incoming user request, it registers its CApplication::handleError() method to handle PHP warnings and notices. It registers its CApplication::handleException() method to handle uncaught PHP exceptions. Consequently, if a PHP warning/notice or an uncaught exception occurs during the application execution, one of the error handlers will take over the control and start the necessary error handling procedure. The registration of error handlers is done in the application's constructor by calling the PHP functions set_exception_handler and set_ error_handler. If you prefer to not have Yii handle these types of errors and exceptions, you may override this default behavior by defining a global constant YII_ENABLE_ERROR_HANDLER and YII_ENABLE_ EXCEPTION_HANDLER to be false in the main index.php entry script. By default, the application will use the framework class CErrorHandler as the application component tasked with handling PHP errors and uncaught exceptions. Part of the task of this built-in application component is displaying these errors using appropriate view files based on whether or not the application is running in debug mode or in production mode. This allows you to customize your error messages for these different environments. It makes sense to display much more verbose error information in a development environment, to help troubleshoot problems. But allowing users of a production application to view this same information could compromise security. Also, if you have implemented your site in multiple languages, CErrorHandler also chooses the most preferred language for displaying the error. You raise exceptions in Yii the same way you would normally raise a PHP exception. One uses the following general syntax to raise an exception when needed: throw new ExceptionClass('ExceptionMessage'); The two exception classes the Yii provides are: • CException • CHttpException CException is a generic exception class. CHttpException represents an exception that is intended to be displayed to the end user. CHttpException also carries a statusCode property to represent an HTTP status code. Errors are displayed differently in the browser, depending on the exception class that is thrown. Iteration 10: Production Readiness [ 318 ] Displaying errors As was previously mentioned, when an error is forwarded to the CErrorHandler application component, it makes a decision as to which view file to use when displaying the error. If the error is meant to be displayed to end users, such as is the case when using CHttpException, the default behavior is to use a view named errorXXX, where XXX represents the HTTP status code (for example, 400, 404, 500). If the error is an internal one and should only be displayed to developers, it will use a view named exception. When the application is in debug mode, a complete call stack as well as the error line in the source file will be displayed. However, this is not the full story. When the application is running in production mode, all errors will be displayed using the errorXXX view files. This is because the call stack of an error may contain sensitive information that should not be displayed to just any end user. When the application is in production mode, developers should rely on the error logs to provide more information about an error. A message of level error will always be logged when an error occurs. If the error is caused by a PHP warning or notice, the message will be logged with category php. If the error is caused by an uncaught exception, the category will be exception.ExceptionClassName, where the exception class name is one of, or child class of, either CHttpException or CException. One can thus take advantage of the logging features, discussed in the previous section, to monitor errors that occur within a production application. By default, CErrorHandler searches for the location of the corresponding view file in the following order: 1. WebRoot/themes/ThemeName/views/system: The system view file under the currently active theme. 2. WebRoot/protected/views/system: The default system view file for an application. 3. YiiRoot/framework/views: The standard system view folder provided by the Yii Framework. So, you can customize the error display by creating custom error view files under the system view folder of the application or theme. Yii also allows you to define a specific controller action method to handle the display of the error. This is actually how our application is configured. We'll see this as we go through a couple of examples. Chapter 13 [ 319 ] Let's look at a couple examples of this in action. Some of the code that was generated for us as a by-product of using the Gii CRUD generator tool to create our CRUD scaffolding is taking advantage of Yii's error handling. One such example is the ProjectController::loadModel() method. That method is defined as follows: public function loadModel() { if($this->_model===null) { if(isset($_GET['id'])) $this->_model=Project::model()->findbyPk($_GET['id']); if($this->_model===null) throw new CHttpException(404,'The requested page does not exist.'); } return $this->_model; } We see that it is attempting to load the appropriate Project model AR instance based on the input id querystring parameter. If it is unable to locate the requested project, it throws a CHttpException as a way to let the user know that the page they are requesting, in this case the project details page, does not exist. We can test this in our browser by explicitly requesting a project that we know does not exist. As we know our application does not have a project associated with an ID of 99, a request for http://localhost/trackstar/project/view/id/99 will result in the following page being returned: Iteration 10: Production Readiness [ 320 ] This is nice, because the page looks like any other page in our application, with the same theme, header, footer, and so on. This is actually not the default behavior for rendering this type of error page. Our initial application was configured to use a specific controller action for the handling of such errors. We mentioned this was another option for how to handle errors in an application. If we take a peek into this configuration file, we see the following code snippet: 'errorHandler'=>array( // use 'site/error' action to display errors 'errorAction'=>'site/error', ), This configures our error handler application component to use the SiteController::actionError() method to handle all of the exceptions intended to be displayed to users. If we take a look at that action method, we notice that it is rendering the protected/views/site/error.php view file. This is just a normal controller view file, so it will also render any relevant application layout files and will apply the appropriate theme. This way, we are able to provide the user with a very friendly experience when certain errors happen. To see what the default behavior is, without this added configuration, let's temporarily comment out the above lines of configuration code (in protected/ config/main.php) and request the non-existent project again. Now we see the following page: As we have not explicitly defined any custom error pages following the convention outlined earlier, this is the error404.php file in the Yii Framework itself. Go ahead and revert these changes to the configuration file to have the error handling use the SiteController::actionError() method. Now let's see how this compares to throwing a CException, rather than the HTTP exception class. Let's comment out the current line of code throwing the HTTP exception and add a new line to throw this other exception class, as follows: public function loadModel() { if($this->_model===null) { Chapter 13 [ 321 ] if(isset($_GET['id'])) $this->_model=Project::model()->findbyPk($_GET['id']); if($this->_model===null) //throw new CHttpException(404,'The requested page does not exist.'); throw new CException('The is an example of throwing a CException'); } return $this->_model; } Now if we make our request for a non-existent project, we see a very different result. This time we see a system generated error page with a full stack trace error info dump along with the specific source file where the error occurred. The results were a little too long to capture in a screenshot, but it will display the fact that a CException was thrown along with the description The is an example of throwing a CException, the source file and then the full stack trace. So throwing this different exception class, along with the fact the application is in debug mode, has a different result. This is the type of information we would like to display to help us troubleshoot the problem, but only as long as our application is running in a secure development environment. Let's temporarily comment out the debug setting in the root index.php file, in order to see what would be displayed when in production mode: // remove the following line when in production mode //defined('YII_DEBUG') or define('YII_DEBUG',true); With this commented out, if we refresh our request for our non-existent project, we see that the exception is displayed as an end-user friendly HTTP 500 error, as depicted in the following screenshot: Iteration 10: Production Readiness [ 322 ] So we see that none of our sensitive code or stack trace information is displayed when in production mode. Caching Caching data is a great method for helping to improve the performance of a production web application. If there is specific content that is not expected to change upon every request, using the cache to store and serve this content can save the time it takes to retrieve and process that data. Yii provides for some nice features when it comes to caching. The tour of Yii's caching features will begin with configuring a cache application component. Such a component is one of several child classes extending CCache, the base class for cache classes with different cache storage implementations. Yii provides many different specific cache component class implementations that store the data utilizing different approaches. The following is a list of the current cache implementations that Yii provides as of version 1.1.2: • CMemCache: Uses the PHP memcache extension. • CApcCache: Uses the PHP APC extension. • CXCache: Uses PHP XCache extension • CEAcceleratorCache: Uses the PHP EAccelerator extension. • CDbCache: Uses a database table to store cached data. By default, it will create and use a SQLite3 database under the runtime folder. You can explicitly specify a database for it to use by setting its connectionID property. • CZendDataCache: Uses Zend Data Cache as the underlying caching medium. • CFileCache: Uses files to store cached data. This is particular suitable to cache large chunk of data (such as pages). • CDummyCache: This presents the consistent cache interface, but does not actually perform any caching. The reason for this implementation is to that if you are faced with situation where your development environment does not have cache support, you can still execute and test your code that will need to use cache once available. This allows you to continue to code to a consistent interface, and when the time comes to actually implement a real caching component. You will not need to change the code written to write to or retrieve data from cache. Chapter 13 [ 323 ] All of these components extend from the same base class, CCache and expose a consistent API. This means that you can change the implementation of the application component in order to use a different caching strategy without having to change any of the code that is using the cache. Configuring for cache As was mentioned, using cache in Yii typically involves choosing one of these implementations, and then configuring the application component for use in the / protected/config/main.php file. The specifics of the configuration will, of course, depend on the specific cache implementation. For example, if one were to use the memcached implementation, that is, CMemCache, which is a distributed memory object caching system that allows you to specify multiple host servers as your cache servers, configuring it to use two servers might look similar to: array( ...... 'components'=>array( ...... 'cache'=>array( 'class'=>'system.caching.CMemCache', 'servers'=>array( array('host'=>'server1', 'port'=>12345, 'weight'=>60), array('host'=>'server2', 'port'=>12345, 'weight'=>40), ), ), ), ); To keep things relatively simple for the reader following along with the TrackStar development, we'll use the filesystem implementation, CFileCache, as we go through some examples. This should be readily available on any development environment that allows access to reading and writing files from the filesystem. If for some reason this is not an option for you, but you still want to follow along with the code examples, simply use the CDummyCache option. As mentioned, it won't actually store any data in the cache, but the code will execute against it just fine. Iteration 10: Production Readiness [ 324 ] CFileCache provides a file-based caching mechanism. When using this implementation, each data value being cached is stored in a separate file. By default, these files are stored under the protected/runtime/cache/ folder, but one can easily change this by setting the cachePath property when configuring the component. For our purposes, this default is fine, so we simply need to add the following to the components array in our /protected/config/main.php configuration file as such: // application components 'components'=>array( … 'cache'=>array( 'class'=>'system.caching.CFileCache', ), … ), With this in place, we can access this new application component anywhere in our running application via Yii::app()->cache. Using a file-based cache Let's try out this new component. Remember that system message we added as part of our administrative functionality in the previous iteration? Rather than get it from the database upon every request, let's store the value initially returned from the database in our cache for a limited amount of time, so that not every subsequent request has to retrieve the data from the database. Let's add a new public method to our SysMessage AR model class to handle the retrieval of the latest system messages. Let's make this new method both public and static so that other parts of the application can easily use this method to access the latest system message without having to explicitly create an instance of SysMessage. This also will help in writing our test. Test? You'd probably thought we forgot all about our test-first approach to development at this point. Well, we haven't, so let's get back to it. Create a new test file, protected/tests/unit/SysMessgeTest.php, and add to it the following a fixture definition and single test method: assertTrue($message instanceof SysMessage); } } Running this test from the command line will immediately fail due to the fact that we have not yet added this new method. Let's add this method to the SysMessage class as follows: /** * Retrieves the most recent system message. * @return SysMessage the AR instance representing the latest system message. */ public static function getLatest() { //see if it is in the cache, if so, just return it if( ($cache=Yii::app()->cache)!==null) { $key='TrackStar.ProjectListing.SystemMessage'; if(($sysMessage=$cache->get($key))!==false) return $sysMessage; } //The system message was either not found in the cache, or //there is no cache component defined for the application //retrieve the system message from the database $sysMessage = SysMessage::model()->find(array( 'order'=>'t.update_time DESC', )); if($sysMessage != null) { //a valid message was found. Store it in cache for future retrievals if(isset($key)) $cache->set($key,$sysMessage,300); return $sysMessage; } else return null; } Iteration 10: Production Readiness [ 326 ] We'll cover the details in just a minute. First, let's get our test to pass. With this in place, if we run our test again, we still get a failure. But this time, the failure is because our method is returning null, and we are testing for a non-null return value. The reason that it is returning null is that there are no system messages in our test database. Remember, our tests are run against the trackstar_test database. Okay, no problem, fixtures to the rescue. Add a new fixture file protected/tests/fixtures/tbl_sys_ message.php which is similar to look this: array( 'message' => 'This is a test message', 'create_time' => new CDbExpression('NOW()'), 'create_user_id' => 1, 'update_time' => new CDbExpression('NOW()'), 'update_user_id' => 1, ), ); Also, ensure that the test case class is configured to be using the fixture by verifying the following code is at the top of the SysMessageTest test class: public $fixtures=array( 'messages'=>'SysMessage', ); Okay, now we can fire off our test again, and this time it succeeds. The method should have tried to retrieve the message from the cache. But, as this was the first time for the request in our test environment, it would not yet be there. So, it proceeded to retrieve it from the database and then store the result into cache for subsequent requests. If we do a folder listing for the default location being used for file caching, protected/runtime/cache/, we do indeed see one strangely named file (yours may be slightly different): 8b22da6eaf1bf772dae212cd28d2f4bc.bin Which if we open in a text editor, reveals the following: a:2:{i:0;O:10:"SysMessage":11:{s:18:"CActiveRecord_md";N;s:19:"18 CActiveRecord_new";b:0;s:26:"CActiveRecord_attributes";a:6:{s:2 :"id";s:1:"1";s:7:"message";s:22:"This is a test message";s:11:"create_time";s:19:"2010-07-08 21:42:00";s:14:"create_user_id";s:1:"1";s:11:"update_time";s:19:"2010- 07-08 21:42:00";s:14:"update_user_id";s:1:"1";}s:23:"18CActiveRecord18_rela Chapter 13 [ 327 ] ted";a:0:{}s:17:"CActiveRecord_c";N;s:18:"CActiveRecord_pk";s :1:"1";s:15:"CModel_errors";a:0:{}s:19:"CModel_validators";N; s:17:"CModel_scenario";s:6:"update";s:14:"CComponent_e";N;s:1 4:"CComponent_m";N;}i:1;N;} This is the serialized, cached value of our most recently updated SysMessage AR class instance, which is exactly what we would expect to be there. So, we see that the caching is actually working. When running tests, executing the application in the test environment, against the test database, we might want to configure a different location to cache our test data. In this case, we might want to add to our test application configuration, protected/config/test.php, a cache component that is configured slightly differently. For example, if we wanted to specify a different folder to place the test cache data, we could add the following to our application components in this test config file: 'cache'=>array( 'class'=>'system.caching.CFileCache', 'cachePath'=> '/Webroot/trackstar/protected/runtime/cache/test', ), This way, we won't alter our test results by reading that was cached from normal use of the main development application. Let's revisit the above code for our new SysMessage::getLatest() method in a bit more detail. The first thing the code is doing is checking to see if the requested data is already in the cache, and if so, returns that value: //see if it is in the cache, if so, just return it if( ($cache=Yii::app()->cache)!==null) { $key='TrackStar.ProjectListing.SystemMessage'; if(($sysMessage=$cache->get($key))!==false) return $sysMessage; } Iteration 10: Production Readiness [ 328 ] As we mentioned, we configured the cache application component to be available anywhere in the application via Yii::app()->cache. So, it first checks to see if there even is such a component defined. If so, it attempts to look up the data in the cache via the $cache->get($key) method. This does more or less what you would expect. It attempts to retrieve a value from cache based on the specified key. The key is a unique string identifier that is used to map to each piece of data stored in the cache. In our system message example, we only need to display one message at a time, and therefore can have a fairly simple key identify the single system message to display. The key can be any string value, as long as it remains unique for each piece of data we want to cache. In this case we have chosen the descriptive string TrackStar. ProjectListing.SystemMessage as the key used when storing and retrieving our cached system message. When this code is executed for the very first time, there will not yet be any data associated with this key value in the cache. Therefore, a call to $cache->get() for this key will return false. So, our method will continue to the next bit of code, which simply attempts to retrieve the appropriate system message from the database, using the AR class: $sysMessage = SysMessage::model()->find(array( 'order'=>'t.update_time DESC', )); We then proceed with the following code that first checks if we did get anything back from the database. If we did, then it stores it in the cache before returning the value, otherwise, null is returned: if($sysMessage != null) { if(isset($key)) $cache->set($key,$sysMessage->message,300); return $sysMessage->message; } else return null; If a valid system message was returned, we use the $cache->set() method to store the data into cache. This method has the following general form: set($key,$value,$duration=0,$dependency=null) When placing a piece of data into cache, one must specify a unique key, as well as the data to be stored. The key is a unique string value, as discussed above, and the value is whatever data desired to be cached. This can be in any format, as long as it can be serialized. The duration parameter specifies an optional time-to-live (TTL) requirement. This can be used to ensure that the cached value is refreshed Chapter 13 [ 329 ] after a period of time. The default is 0, which means it will never expire, that is, it will live forever in the cache. (Actually, internally, Yii translates a value of <=0 for the duration to mean that it should expire in one year. So, not exactly forever, but definitely a long time). We are calling the set() method in the following manner: $cache->set($key,$sysMessage->message,300); We set the key to be what we had it defined as before, TrackStar.ProjectListing. SystemMessage, the data being stored is the message attribute of our returned SystemMessage AR class, that is, the message column of our tbl_sys_message table, and then we set the duration to be 300 seconds. This way, the data in the cache will expire every five minutes, at which time the database is queried again for the most recent system message. We did not specify a dependency when we set the data. We'll discuss this optional parameter next. Cache dependencies The dependency parameter allows for an alternative and much more sophisticated approach to deciding whether or not the stored data in the cache should be refreshed. Rather than declaring a simple time period for the expiration of cached data, your caching strategy may require that the data become invalid based on things like the specific user making the request, or the general mode or state of the application, or whether a file on the filesystem has been recently updated. This parameter allows you to specify such cache validation rules. The dependency is an instance of CCacheDependency or its child class. Yii makes available the following specific cache dependencies: • CFileCacheDependency: The data in the cache will be invalid if the specified file's last modification time has changed since the previous cache lookup. • CDirectoryCacheDependency: Similar to the above for the file cache dependency, but this checks all the files and subdirectories within a given specified folder. • CDbCacheDependency: The data in the cache will be invalid if the query result of a specified SQL statement is changed since the previous cache lookup. • CGlobalStateCacheDependency: The data in the cache will be invalid if the value of the specified global state is changed. A global state is a variable that is persistent across multiple requests and multiple sessions in an application. It is defined via CApplication::setGlobalState(). Iteration 10: Production Readiness [ 330 ] • CChainedCacheDependency: This allows you to chain together multiple dependencies. The data in the cache will become invalid if any of the dependencies on the chain is changed. • CExpressionDependency: The data in the cache will be invalid if the result of the specified PHP expression is changed. To provide a concrete example, let's use a dependency to expire the data in the cache whenever a change to the tbl_sys_message database table is made. Rather than arbitrarily expire our cached system message after five minutes, we'll expire it exactly when we need to, that is, when there has been a change to the update_time column for one of the system messages in the table. We'll use the CDbCacheDependency implementation to achieve this, since it is designed to invalidate cached data based on a change in the results of a SQL query. We alter our call to the set() method to set the duration time to 0, so that it won't expire based on time, but pass in a new dependency instance with our specified SQL statement as such: $cache->set($key, $sysMessage->message, 0, new CDbCacheDependency('select id from tbl_sys_message order by update_ time desc')); Changing the duration TTL time to 0 is not at all a prerequisite of using a dependency. We could have just as easily left the duration in as 300 seconds. This would just stipulate another rule to render the data in the cache invalid. The data would only be valid in the cache for a maximum of five minutes, but would also be regenerated prior to this time limit if there as a change to the update_time column occurred on one or more records in the table. With this in place, the cache will expire only when the results of the query statement are changed. This example is a little contrived, since we were originally caching the data to avoid a database call altogether. Now we have configured it to execute a database query every time we attempt to retrieve data from cache. However, if the cached data was a much more complex data set, that involved much more overhead to retrieve and process, a simple SQL statement for cache validity could make a lot of sense. The specific caching implementation, the data stored, the expiration time as well as any other data validation in the form of these dependencies will all depend on the specific requirements of the application being built. It is good to know that Yii has many options available to help meet our varied requirements. To complete the changes to our application to take advantage of the caching of data in our new method, we still need to refactor the ProjectController::actionIn dex() method to use this newly create method. This is easy. Just replace the code Chapter 13 [ 331 ] that was generating the system message from the database, with a call to this new method. That is, in ProjectController::actionIndex(), simply change this: $sysMessage = SysMessage::model()->find(array('order'=>'t.update_time DESC',)); to the following: $sysMessage = SysMessage::getLatest(); Now the system message being displayed on the projects listing page is taking advantage of the file cache. Fragment caching The previous example demonstrates the use of data caching. This is where we take a single piece of data and store it in the cache. There are other approaches available in Yii to store fragments of pages generated by a portion of a view script, or even the entire page itself. Fragment caching refers to caching a fragment of a page. We can take advantage of fragment caching inside of view scripts. To do so, we use the CController::beginCache() and CController::endCache() methods. These two methods are used to mark the beginning and the end of the rendered page content that should be stored in cache. Just as is the case when using a data caching approach, we need a unique key to identify the content being cached. In general, the syntax for using fragment caching inside of a view script is as follows: ...some HTML content... beginCache($key)) { ?> ...content to be cached... endCache(); } ?> ...other HTML content... If the call to beginCache() returns false, the cached content will be automatically inserted at that place; otherwise, the content inside the if statement will be executed and will be cached when endCache() is invoked. Declaring fragment caching options When calling beginCache(), we can supply an array as the second parameter consisting of caching options to customize the fragment caching. As a matter of fact, the beginCache() and endCache() methods are a convenient wrapper of the COutputCache filter/widget. Therefore, the caching options can be initial values for any properties of COutputCache. Iteration 10: Production Readiness [ 332 ] Arguably one of the most common options specified when caching data is the duration, which specifies how long the content can remain valid in the cache. It is similar to the duration parameter we used when using the data caching approach for our system messages. You can specify the duration parameter when calling beginCache() as follows: $this->beginCache($key, array('duration'=>3600)) The default setting for this fragment caching approach is different than that for the data caching. If we do not set the duration, it defaults to 60 seconds, meaning the cached content will be invalidated after 60 seconds. There a many other options you can set when using the fragment caching. For more information, refer to the API documentation for COutputCache as well as the fragment caching section of the definitive guide, available on the Yii Framework site: http://www.yiiframework. com/doc/guide/caching.fragment Using fragment cache Let's implement this in our TrackStar application. We'll again focus on the project listings page. As you recall, towards the bottom of this page, there is a list of the comments that users have left on the issues associated with each project. This list indicates who left a comment on which issue. Rather than re-generate this list upon each request, let's use fragment caching to cache this list for, say, two minutes. The application can tolerate this data being slightly stale, and two minutes is really not that long to have to wait for an updated comment list. To do this, we make our changes to the listing view file, protected/views/ project/index.php. We'll wrap the call to our entire recent comments portlet inside this fragment caching approach, as such: beginCache($key, array('duration'=>120))) { $this->beginWidget('zii.widgets.CPortlet', array( 'title'=>'Recent Comments', )); $this->widget('RecentComments'); $this->endWidget(); $this->endCache(); } ?> Chapter 13 [ 333 ] With this in place, if we visit the project listings page for the first time, our comments list will be stored in the cache. If we then quickly (by quickly, we mean before two minutes have elapsed) add a new comment to one of the issues within a project, and then toggle back to the project listings page, we won't immediately see the newly added comment. But if we keep refreshing the page, once the content in the cache expires (a maximum of two min in this case), the data will be refreshed, and our new comment will be displayed in the listing. You could also simply add an echo time(); PHP statement to the above cached content to see if it is working as expected. If the content is properly caching, the time display will not update until the cache is refreshed. When using the file cache, remember to ensure that your /protected/ runtime/ folder is writable by the web server process, as this is where the cache content is stored by default. Page caching In addition to fragment caching, Yii offers options to cache the results of the entire page request. Page caching is similar to that of fragment caching. However, because the content of an entire page is often generated by applying additional layouts to a view, we can't simply call beginCache() and endCache() in the layout file. The reason is because the layout is applied within the call to the CController::render() method after the content view is evaluated. So, we would always miss the opportunity to retrieve the content from the cache. Therefore, to cache a whole page, we should entirely skip the execution of the action generating the page content. To accomplish this, we can use COutputCache class as an action filter in our controller class. Let's provide an example. Let's use the page caching approach to cache the page results for every project detail page. The project detail pages in TrackStar are rendered by requesting URLs of the format, http://localhost/trackstar/ project/view/id/[id], where [id] is the specific project ID we are requesting the details of. What we want to do is set up a page caching filter that will cache the entire contents of this page, separately for every ID requested. We need to incorporate the project ID into the key value when we cache the content. That is, we don't want to make a request for the details of project #1, and have the application return a cached result for project #2. Luckily, the COutputCache filter anticipated this need. Iteration 10: Production Readiness [ 334 ] Open protected/controllers/ProjectController.php and alter the existing filters() method as such: public function filters() { return array( 'accessControl', // perform access control for CRUD operations array( 'COutputCache + view', //cache the entire output from the actionView() method for 2 minutes 'duration'=>120, 'varyByParam'=>array('id'), ), ); } This filter configuration utilizes the COutputCache filter to cache the entire output generated by the application from a call to ProjectController::actionView(). The + view added just after the COutputCache declaration, as you may recall, is the standard way we include specific action methods to which a filter should apply. The duration parameter specifies a TTL of 120 seconds (2 min), after which the page content will be regenerated. The varyByParam configuration is a really great option that we alluded to before. Rather than putting the responsibility on you, the developer, to come up with a unique key strategy for the content being cached, this feature allows the variation to be handled automatically. In this case, by specifying a list of names that correspond to GET parameters in the input request. Since we are caching the page content of requests for projects by project_id, it makes perfect sense to use this id as part of the unique key generation for caching the content. By specifying 'varyByParam'=>array('id'), COutputCache does this for us, based on the input querystring parameter, id. There are more options available to achieve this type of auto content variation strategy when using COutputCache to cache our data. As of this writing, the following variation features are available to use: • varyByRoute: By setting this option to true, the specific request route will be incorporated into the unique identifier for the cached data. Therefore, you can use the combination of the requested controller and action to distinguish cached content. • varyBySession: By setting this option to true, the unique session id is used distinguish the content in the cache. Each user session may see different content but all of this content can still be served from the cache. Chapter 13 [ 335 ] • varyByParam: As discussed previously, this uses the input GET querystring parameters to distinguish the content in the cache. • varyByExpression: By setting this option to a PHP expression, we can use the result of this expression to distinguish the content in the cache. So, with the above filter configured in our ProjectController class, each request for a specific project details page is stored in the cache for up to two minutes before being regenerated and again stored in the cache. You can test this out by first viewing a specific project, then updating that project in some way. Your updates will not immediately display if done within the TTL of two minutes. Caching entire page results is a great way to improve site performance, however it certainly does not make sense for every page in every application. A combination of the above three approaches: data, fragment and page caching, will probably need to be implemented in most real-world applications. We have really just scratched the surface of all caching options available within Yii. Hopefully this has whet your appetite to further investigate the full caching landscape available. General performance tuning tips Before we wrap up this final iteration, we'll briefly outline some other areas of consideration when working to tweak the performance of a Yii-based web application. These more or less come straight from the Performance Tuning section of the Yii definitive guide, http://www.yiiframework.com/doc/guide/topics. performance. But it is good to restate them here for completeness and general awareness. Using APC Enabling the PHP APC extension is perhaps the easiest way to improve the overall performance of an application. The extension caches and optimizes PHP intermediate code and avoids the time spent in parsing PHP scripts for every incoming request. Disabling debug mode We discussed this earlier in the chapter, but it won't hurt to hear it again. Disabling debug mode is another easy way to improve performance and security. A Yii application runs in debug mode if the constant YII_DEBUG is defined as true in the main index.php entry script. Many components, including those down in the framework itself, incur extra overhead when running in debug mode. Iteration 10: Production Readiness [ 336 ] Using yiilite.php When the PHP APC extension is enabled, one can replace yii.php with a different Yii bootstrap file named yiilite.php. This can help to further boost the performance of a Yii-powered application. The file yiilite.php comes with every Yii release. It is the result of merging some commonly used Yii class files. Both comments and trace statements are stripped from the merged file. Therefore, using yiilite.php would reduce the number of files being included and avoid execution of trace statements. Note, using yiilite.php without APC may actually reduce performance, because yiilite.php contains some classes that are not necessarily used in every request and would take extra parsing time. It is also observed that using yiilite.php is slower with some server configurations, even when APC is turned on. The best way to judge whether to use yiilite.php or not is to run a benchmark using the included hello world demo. Using caching techniques As we described and demonstrated in this chapter, Yii provides many caching solutions that may improve the performance of a web application significantly. The available caching systems are as follows: • If the generation of some data takes long time, we can use the data caching approach to reduce the data generation frequency • If a portion of page remains relatively static, we can use the fragment caching approach to reduce its rendering frequency • If a whole page remains relative static, we can use the page caching approach to save the rendering cost for the whole page Enabling schema caching If the application is using Active Record, one can turn on the schema caching in a production environment to save the time of parsing database schema. This can be done by configuring the CDbConnection::schemaCachingDuration property to be a value greater than 0. Besides these application-level caching techniques, we can also use server-side caching solutions to boost the application performance. The enabling of APC caching that we described above belongs to this category. There are other server-side techniques, such as Zend Optimizer, eAccelerator and Squid, just to name a few. Chapter 13 [ 337 ] These, for the most part, just provide some good-practice guidelines as you work to prepare your Yii application for production, or as you troubleshoot an existing application for bottlenecks. General application performance tuning is much more art than science, and there are many, many factors outside of the Yii Framework that play into the overall performance. Yii has been built with performance in mind since its inception and continues to out-perform many other PHP-based application development frameworks by a long shot (see http://www.yiiframework.com/ performance/ for more details). Of course, every single web application will need to be tweaked to enhance its performance, but making Yii the development framework of choice certainly puts your application on a great performance footing from the onset. Summary In this final iteration, we turned our attention to making changes to our application to help improve its maintainability and performance in a production environment. We first covered application logging strategies available in Yii, and how to log and route messages based on varying severity levels and categories. We then turned focus to error handling and how Yii exploits the underlying exception implementation in PHP 5 to provide a flexible and robust error handling framework. We then learned about some different caching strategies available in Yii. We learned about the caching of application data and content at varying levels of granularity. Data caching for specific variables or individual pieces of data, fragment caching for content areas within pages, and full page caching to cache the entire rendered output of a page request. Finally, we provided a list of "good practices" to follow when working to improve the performance of a Yii-powered Web application. Unfortunately, our TrackStar application is actually quite far from a complete, full featured task management system, and even many of the concepts covered were left to the reader to fully implement. However, a nice foundation on which to build has been laid, and now that you have the power of Yii on your side, you could very quickly turn this into a much more useable and feature-rich application. Also a great many of the examples covered will translate well to other types of Web applications you may be building. Good luck with your future projects, and happy developing! Index Symbols $dsn variable about 57 formats 57 $pageTitle attribute 261 A accessControl filter 114 about 173 implementing 174, 175 access rules about 176 actions 176 controllers 176 expression 176 ips 176 roles 176 users 176 verbs 176 accessRules() method 175, 203 actionAdduser() method 203-212 actionAdmin() contorller action 176 actionCreate() method 12, 114 actionDelete() controller action 176 actionFeed() method 244 actionGoodbye() method 31 actionHelloWorld() method 25, 28, 44 actionID parameter 25 actionIndex() method 12, 26, 129 actionLogin() method 208, 263 actionShow() method 12 actionUpdate() method 114 actionView() method 114, 129, 220 Active Record (AR) 10, 14 Active Record model classes creating 98 issue model class, creating 98-100 user model class, creating 101 addChild() method 182 admin module building 295-298 AdminModule::beforeControllerAction() method 296 afterValidate() method 159 anonymous user 36 AR model class creating 64 creating, Gii used 66-68 Gii, configuring 65 stesting 68 assertEquals() 50 associateUserToProject() method 202 Attribute List 79 AuthAssignment table 180 authenticated user 36 authenticate() method 163 AuthItemChild table 180 AuthItem table 180 authManager component 179 authorization item 178 authorization level checking 211, 212 authorization manager, RBAC configuring 179 B basic entity relationship about 96 diagrammatic representation 96 [ 340 ] beforeValidate() method 217 beginCache() method 331 beginContent() method 268 bindValue() method 193 blog posting example 11, 12 Blueprint CSS framework 259 Blueprint installation 260 C cache configuring 323 dependencies 329 file-based cache 324-328 fragment caching 331 page caching 333 cache dependencies about 329 CCacheDependency 329 CChainedCacheDependency 330 CDbCacheDependency 329 CDirectoryCacheDependency 329 CExpressionDependency 330 CFileCacheDependency 329 CGlobalStateCacheDependency 329 cache, Yii about 322 CApcCache 322 CDbCache 322 CDummyCache 322 CEAcceleratorCache 322 CFileCache 322 CMemCache 322 CXCache 322 CZendDataCache 322 caching 322 caching techniques 336 CActiveForm class 110 CActiveForm::labelEx() method 109 CActiveForm::textField() method 109 CActiveForm widget 108 CActiveRecord 67 CActiveRecord::beforeValidate() method 153 CActiveRecord class 10 CApcCache 322 CApplication::findLocalizedFile() method 283 CApplication::handleError() method 317 CBreadcrumbs 265 CController base class 114 CController::beginCache() method 331 CController::endCache() method 331 CController::render() method 333 CController::renderPartial() method 255 CDbAuthManager component 179 CDbCache 322 CDbCommand class 193 CDbConnection class 57 CDbConnection::tablePrefix property 64 CdbFixtureManager class 86 CDbMessageSource 281 CDetailView widget 138 CDummyCache 322 CEAcceleratorCache 322 CErrorHandler 317, 318 CException 317 CFileCache 322 CFileLogRoute message routing 314 CFormModel class 10 CGettextMessageSource 281 checkAccess() method 191 CHtml 32 CHtml helper class 34, 124 CHtml::listData() method 124 CListView widget 137 CMemCache 322 CommentController::accessRules() method 244 comment CRUD creating 218 Comment::findRecentComments() method 226 Comment::relations() method 218 Common Locale Data Repository (CLDR) 279 configuration, Yii 19 controller 10, 14 controller command 25 controller method 108 COutputCache class 333 COutputCache filter 334 CPhpAuthManager component 179 CPhpMessageSource 281 [ 341 ] CPortlet 235, 236 createAbsoluteUrl() method 243 createCommand() method 193 createOperation() method 182 createRole() method 182 createUrl() method 243 CRUD operations implementing, for issues 128 CRUD operations, enabling CRUD scaffolding, creating 74-77 for users 73 new project, creating 77, 78 new project, reading 82 projects, deleting 83 projects, managing in admin console 83, 85 projects, updating 83 required field, adding to form 78-82 CRUD operations implementation, for issues about 128 issues, listing 129 ProjectController, altering 129, 130 project view file, altering 130-132 CWebApplication class 255 CWidget about 225 relational AR queries, executing 227, 228 test, completing 229-231 CXCache 322 CZendDataCache 322 D database connection, TrackStar application about 55 component 58, 59 testing 55, 56 databases MySQL 57 Oracle 57 PostgreSQL 57 SQLite 57 SQL Server 57 Data Definition Language (DDL) 63 Data Definition Language (DDL) statements 96 data scheme defining 39, 40 DBMS about 57 connection, establishing 57 debug mode disabling 335 development methodology automated software testing 41 benefits, of testing 42 defining 41 TDD 43 unit and functional testing 41 Document Object Model (DOM) 306 DOMDocument::createElement() method 243 dropDownList() method 110 dynamic content adding, to view template 28 dynamic content, adding data creation, moving to controller 29, 30 date and time, adding 28 E eager loading 228 endCache() method 331 endContent() method 268 error handling about 316 errors, displaying 318-321 exception classes CException 317 CHttpException 317 F false parameter 70 file-based cache about 324 implementing 324-328 filters() method 175 final changes, issues issue detail view, changing 137-139 owner and requester names, getting to display 139 relational AR, using 139, 140 status and type text, getting to display 132, 134 [ 342 ] text display, adding to form 136 final navigation tweaks, issues making 141-144 findAll() method 228 findByPk() method 71 find() method 228 findRecentComments() method 228 fixture manager configuring 86 fixtures about 85 configuring 88 creating 86 flash message 208 fragment caching about 331 options, declaring 331 using 332, 333 functional tests about 42, 45 Selenium, installing 45 test example, running 46, 47 G getHelp() method 186 getRecentComments() method 233 getRoles() method 202 getStatusText() method 138 getter method 126 getTypeOptions() method 106, 110 getTypeText() method 138 getUserOptions() method 126 getUserRoleOptions() method 202 Gii about 64 configuring 65 H hasFlash() method 210 Hello World! example about 22 building 22 controller, creating 22-26 helloWorld.php view, customizing 26, 27 request routing, reviewing 27 helper class 108 I importArray() method 243 init() method 233, 293 installation database 19 Yii 17 internationalization (i18n) 278 issue creating 103, 104 dropdown menu, adding for types 104 types 104 Issue AR class 220 Issue::attributeLabels() method 109 Issue class 107 IssueController::actionAdmin() method 142 IssueController::actionCreate() method 118 IssueController::actionIndex() method 142 IssueController::actionView() method 220-232 IssueController class 112 IssueController::filters() method 114 issue creation process drop-down menu, adding 104 issue type dropdown, adding 107-109 status dropdown, adding 111 test, getting in red 105 test, moving red to green 105 test, moving to green 107 test, moving to red 106 Issue CRUD operations creating 101, 102 using 102 Issue::getStatusText() method 139 Issue::getTypeOptions() method 107 Issue::getTypeText() method 139 issue management functionality Active Record model classes, creating 98 iteration planning 93 relationships, defining 95 schema, designing 95 tables and relationships, creating 96, 97 test suite, running 94 Issue model attribute 109 issue model class about 108 creating 98 [ 343 ] Issue.php model class 110 issue::relations() method 140, 217 Issue::rules() method 109 issues final tweaks 132 listing 129 ProjectController, altering 129, 130 project view file, altering 130, 131 Issue::search() model class method 144 isUserInProject() method 202 isUserInRole() method 197 L language translation about 280 file translation, performing 283, 284 message translation, performing 280-282 performing 280 last_login_time attribute 155 layout about 254 nesting 267, 268 layout files about 254 lazy loading 227 localization (L10n) 278 logging about 309 categories 311 levels 311 login message log, adding 312, 313 message logging 310, 311 message routing 313-316 LoginForm::attributeLabels() method 282 login() method 164 logPath property 316 M main.php layout file, deconstructing about 257 Blueprint CSS Framework, introducing 259 breadcrumb navigation, creating 265 content, specifying 266 footer, defining 267 menu navigation items, displaying 263, 264 page header, defining 261, 262 page title, setting 260 MessageController class 25, 47 message logging 310, 311 message routes CDbLogRoute 314 CEmailLogRoute 314 CProfileLogRoute 314 CWebLogRoute 314 message routing 313-316 message sources, Yii CDbMessageSource 281 CGettextMessageSource 281 CPhpMessageSource 281 model about 10 active record model 10 Form model 10 model, user comments creating 216, 217 module about 288 creating 288-291 system-wide message, adding 298 theme, applying 293-295 theming 292, 293 using 291 MVC architecture, Yii about 9 controller 10 model 10 view 10 O Object-relational mapping 13 on parameter 79 owner and requester dropdowns changing 119-121 data, generating 122, 123 fields, removing 127, 128 ProjectUserAssignment fixture, adding 124-127 user fixture, adding 124-127 owner and requester fields, fixing about 112 filter, adding 113 filtered actions, specifying 114 [ 344 ] filter, implementing 113 filter logic, adding 115, 116 project context, enforcing 112 project details page, altering 117 project id, adding 117 project input form field, removing 118, 119 P page caching 333, 334 performance tuning tips about 335 APCextension , using 335 caching techniques, using 336 debug mode, disabling 335 schema caching, enabling 336 yiilite.php, using 336 PHP APC extension enabling 335 PHPUnit installing 45 Portlets 215 PostgreSQL 63 private $_project attribute 126 production environment caching 322 error handling 316 iteration planning 309 logging 309 performance tuning tips 335 preparing 309 production mode 322 Project AR class, testing about 68 create, testing 69, 70 delete, testing 72 read, testing 71 unit test file, creating 69 update, testing 72 Project::associateUserToRole() method 193 project attribute 126 projectContext filter 114 ProjectController::accessRules() method 174 ProjectController::actionIndex() method 249-330 ProjectController::actionView() method 250 ProjectController class 129 ProjectController::filters() method 174 ProjectController::loadModel() method 319 project CRUD AR model class, creating 64 CRUD operations, enabling 73 iteration planning 61 project table, creating 62 test suite, running 62 project_id attribute 119 project_id property 119 project issues, TrackStar application bugs, categories 37 categories 37 features, categories 37 tasks, categories 37 Project::isUserInRole() method 196 Project::relations() method 121 project table creating 62, 63 naming conventions 63, 64 ProjectTest::testCreate() method 151 public method 192 Q querystring parameter 117, 319 querystring variable 12 R RBAC authorization hierarchy console application command, writing 182-188 creating 181 RBAC database tables AuthAssignment table 180 AuthItemChild table 180 AuthItem table 180 creating 180 RBAC roles adding, to projects 189 new Project AR methods, implementing 191-201 RBAC business rules, adding 190, 191 RBAC users, assigning to projects about 202 new action method, adding to project controller 207, 208 [ 345 ] new form model class, adding 205 new view file, adding to diplay form 208, 210 Project model class, altering 203, 204 Really Simple Syndication 240 recent comments widget creating 224 relational AR queries eager loading 228 executing 227, 228 lazy loading 227 relations() method 120 render() 31 render() method 256 renderPartial() 292 repeat() 51 request routing, Yii about 11 blog posting example 11, 12 Reversish translations 281 role-based access control (RBAC) about 171-179 authorization hierarchy, creating 181, 182 authorization manager, configuring 179 business rules, adding 190, 191 database tables, creating 180 roles, adding to projects 189, 190 users, assigning to projects 202, 203 users, assigning to roles 188, 189 RSS feed about 239 iteration planning 239 rules() method 78, 155 run() method 186, 233 S save() method 70, 153 scaffolding 74 scaffolding code, user comments altering 218 comment, adding 220 form, displaying 221, 222 schema caching enabling 336 Selenium installing 45 setAttributes() method 70, 151 setFlash() method 208 SiteController 12 SiteController::actionLogin() method 268, 312 SiteController class 311 SomeMethodName 113 static method 210 statusCode property 317 SysMessageController::accessRules() method 302 system-wide message, adding to module CRUD scaffolding, creating 300 database table, creating 298 link, adding 301, 303 message, displaying to users 303 model, creating 299 system-wide message, displaying to users design tweak, adding 305, 306 most recently updated message, selecting 304 new model class, importing for application-wide access 303 T tbl_project table 68 TDD about 43 implementing, in testing framework 47-51 testActionHelloworld() method 44 testCreate() method 90 testCRUD() method 69 test database specifying 89 specifying, fixtures used 90 testDelete() method 90 Test-driven development. See  TDD test fixture 85 testing benefits 42 testing fixtures about 85 fixture, configuring 88 fixture, creating 86, 87 fixture manager, configuring 86 test database, specifying 89 [ 346 ] test database, specifying with fixtures 90, 92 testing, Yii about 43 TDD approach, implementing 47-51 testRepeat() method 49 testUserAccessBasedOnProjectRole() method 201 themes creating 270 TrackStar 35 TrackStarActiveRecord base class 217 TrackStar application configuring, to use theme 277 designing, with layouts 254 internationalization (i18n) 278 language, defining 279 language translation, performing 280 layout, applying 255, 256 layouts, nesting 267 layout, specifying 255 layout, using 255, 256 locale, defining 279 localization (L10n) 278 main.php layout file, deconstructing 257-259 themes, creating 270 application flow 38, 39 caching 322 database, connecting 55 database connection, testing 55, 56 data scheme, defining 39, 40 development methodology, defining 41 error handling 316 iteration planning 53, 54 logging 309 navigation and page flow 38 performance tuning tips 335 project issues 37 projects, managing 36, 37 user stories, creating 36 Yii web application, creating 54 translating, to other languages 278 trackstar_dev database 63, 122 type_id attribute 109 U unit tests about 42, 44 PHPUnit, installing 45 url manager about 245, 246 entry script, removing from url 247-249 routing rules, configuring 246, 247 using 246 user access requirements accessControl filter 173 access rules 176 authorization level, checking 211, 212 iteration planning 172 ProjectController::accessRules() method 174 ProjectController::filters() method 174 test suite, running 173 user authentication application user attributes, extending 166, 167 authenticate implementation, changing 165, 166 database used 160 Yii authentication model, introducing 160-164 user comments comment CRUD, creating 218 iteration planning 215 model, creating 216, 217 recent comments widget, creating 224 scaffolding code, altering 218 user CRUD common audit history columns, updating 150-155 creating 149, 150 password confirmation field, adding 157 password encryption, adding 159, 160 user friendly URLs creating 244, 245 feed links, adding 249, 251 url manager used 245, 246 UserIdentity::authenticate() method 163 user last login time displaying, on home page 169 updating 168 [ 347 ] user management iteration planning 147 test suite, running 148 user CRUD, creating 149, 150 user last login time, updating 168 users, authenticating 160 user model class creating 101 User::rules() method 155 user stories, TrackStar application creating 36 project issues 37 projects 36 users 36 users, TrackStar about 36 anonymous user 36 authenticated user 36 V validate() method 164 Validator 79 Validator class aliases boolean 80 captcha 80 compare 80 default 80 email 80 exist 80 file 80 filter 80 in 80 length 80 match 80 required 80 type 80 unique 81 varyByExpression 335 varyByParam 335 varyByParam configuration 334 varyByRoute 334 varyBySession 334 verify() method 202 view 10, 14 W webapp command 20, 182 Web Content Syndication 240 web pages, linking about 31 CHtml, using 32, 33 new page, linking to 31 widget adding, to another page 236 creating 225-234 with() method 228 Y Yii message sources 281 themes, building 270 Active Record 14 Active Record (AR) 14 application, creating 19 blog posting example 11, 12 controller 14 databases 57 downloading 17 dynamic content, adding 28 efficiency 8 exception classes 317 extensibility 9 features 8, 9 functional tests 45 Hello World! program 22 installing 17 logging 310 message routes 314 MVC architecture 9 Object-relational mapping 13 overview 7 request routing 11 testing 43 unit tests 44 user-friendly 9 view 14 web pages, linking 31 web request lifecycle 11 [ 348 ] yiic command 21 Yii controller. See  controller yiic shell command 182 yiic tool 25, 182 yiic webapp command 313 yiic webapp console command 44 Yii DAO 57 Yii installation about 17 configuration 19 database, installing 19 ensuring 18 yiilite.php using 336 Yii::log method 311 Yii theme creating 270-276 Yii::trace method 311 Yii web application creating 19-22 dynamic content, adding 28 Yii web request lifecycle 11 Yii widget 225 Z Zend_Feed about 240, 241 using 241-243 Zend Framework about 240 installing 241 Zii 9 Thank you for buying Agile Web Application Development with Yii1.1 and PHP5 About Packt Publishing Packt, pronounced 'packed', published its first book "Mastering phpMyAdmin for Effective MySQL Management" in April 2004 and subsequently continued to specialize in publishing highly focused books on specific technologies and solutions. Our books and publications share the experiences of your fellow IT professionals in adapting and customizing today's systems, applications, and frameworks. Our solution based books give you the knowledge and power to customize the software and technologies you're using to get the job done. Packt books are more specific and less general than the IT books you have seen in the past. Our unique business model allows us to bring you more focused information, giving you more of what you need to know, and less of what you don't. Packt is a modern, yet unique publishing company, which focuses on producing quality, cutting-edge books for communities of developers, administrators, and newbies alike. For more information, please visit our website: www.packtpub.com. About Packt Open Source In 2010, Packt launched two new brands, Packt Open Source and Packt Enterprise, in order to continue its focus on specialization. This book is part of the Packt Open Source brand, home to books published on software built around Open Source licences, and offering information to anybody from advanced developers to budding web designers. The Open Source brand also runs Packt's Open Source Royalty Scheme, by which Packt gives a royalty to each Open Source project about whose software a book is sold. Writing for Packt We welcome all inquiries from people who are interested in authoring. Book proposals should be sent to author@packtpub.com. If your book idea is still at an early stage and you would like to discuss it first before writing a formal book proposal, contact us; one of our commissioning editors will get in touch with you. We're not just looking for published authors; if you have strong technical skills but no writing experience, our experienced editors can help you develop a writing career, or simply get some additional reward for your expertise. AJAX and PHP: Building Modern Web Applications 2nd Edition ISBN: 978-1-847197-72-6 Paperback: 308 pages Build user friendly Web 2.0 Applications with JavaScript and PHP 1. The ultimate AJAX tutorial for building modern Web 2.0 Applications 2. Create faster, lighter, better web applications by using the AJAX technologies to their full potential 3. Leverage the power of PHP and MySQL to create powerful back-end functionality and make it work in harmony with a responsive AJAX clientWrite better JavaScript code to enable powerful web features Zend Framework 1.8 Web Application Development ISBN: 978-1-847194-22-0 Paperback: 380 pages Design, develop, and deploy feature-rich PHP web applications with this MVC framework 1. Create powerful web applications by leveraging the power of this Model-View-Controller-based framework 2. Learn by doing – create a "real-life" storefront application 3. Covers access control, performance optimization, and testing 4. Best practices, as well as debugging and designing discussion Please check www.PacktPub.com for information on our titles Building Websites with PHP-Nuke ISBN: 978-1-904811-05-3 Paperback: 320 pages A practical guide to creating and maintaining your own community website with PHP-Nuke 1. Step through creating your own web portal with PHP-Nuke 2. Simple and practical guidance to mastering PHP-Nuke 3. For people with basic knowledge of web development PHP and script.aculo.us Web 2.0 Application Interfaces ISBN: 978-1-847194-04-6 Paperback: 264 pages Build powerful interactive AJAX applications with script.aculo.us and PHP 1. Get started quickly with script.aculo.us library with as little as one line of code 2. Explore Prototype library features, tutorials, code, and examples 3. Learn script.aculo.us' In-place Editing, Auto Completion, Sliders, Drag-and-Drop, Effects, and Multimedia 4. A book with less jargon, and more code explanation for building real-world examples —Tadalist clone, Digg and Delicious clones, 43 things.com clone Please check www.PacktPub.com for information on our titles Magento 1.3: PHP Developer's Guide ISBN: 978-1-847197-42-9 Paperback: 260 pages Design, develop, and deploy feature-rich Magento online stores with PHP coding 1. Extend and customize the Magento e-commerce system using PHP code 2. Set up your own data profile to import or export data in Magento 3. # Build applications that interface with the customer, product, and order data using Magento's Core API jQuery UI 1.7: The User Interface Library for jQuery ISBN: 978-1-847199-72-0 Paperback: 392 pages Build highly interactive web applications with ready- to-use widgets from the jQuery User Interface library 1. Organize your interfaces with reusable widgets: accordions, date pickers, dialogs, sliders, tabs, and more 2. Enhance the interactivity of your pages by making elements drag-and-droppable, sortable, selectable, and resizable 3. Packed with examples and clear explanations of how to easily design elegant and powerful front-end interfaces for your web applications 4. Revised and targeted at jQuery UI 1.7 Please check www.PacktPub.com for information on our titles Drupal E-commerce with Ubercart 2.x ISBN: 978-1-847199-20-1 Paperback: 364 pages Build, administer, and customize an online store using Drupal with Ubercart 1. Create a powerful e-shop using the award- winning CMS Drupal and the robust e-commerce module Ubercart 2. Create and manage the product catalog and insert products in manual or batch mode 3. Apply SEO (search engine optimization) to your e-shop and adopt turn-key internet marketing techniques PrestaShop 1.3 Beginner's Guide ISBN: 978-1-849511-14-8 Paperback: 308 pages Build and customize your online store with this speedy, lightweight e-commerce solution 1. Covers every topic required to start and run a real, trading e-commerce business with PrestaShop 2. Deploy PrestaShop quickly and easily, and make your PrestaShop search-engine friendly 3. Learn how to turn a single new PrestaShop into a thriving e-commerce empire 4. Step-by-step fully illustrated explanation and discussions aimed at helping beginners like you towards the realization of your own PrestaShop store and beyond Please check www.PacktPub.com for information on our titles