Also available in these languages:

Scaffolding

Create, read, update and delete (CRUD) are the four basic operations of data objects in an application. Because the task of implementing the CRUD operations is so common when developing Web applications, Yii provides a tool to automate this process (also known as scaffolding). In this section, we will describe how to use the tool to implement CRUD for posts and comments.

Open a command window and run the following commands:

% /wwwroot/yii/framework/yiic shell /wwwroot/blog/index.php
Yii Interactive Tool v1.1
Please type 'help' for help. Type 'exit' to quit.
>> model *
......
>> crud Post
......
>> crud Comment
......
>> exit

Info: Some PHP installations may use a different php.ini file for command line (CLI) PHP parser. As a result, when running the above yiic commands, you may encounter errors like "YiiBase::include(PDO.php): failed to open stream..." or "...could not find driver". Please double check your CLI PHP configuration by executing the following command:

php -i

The result of the above command will show which php.ini file is being used and which extensions are loaded. If a wrong php.ini file is used, you may use the following command to explicitly specify the correct php.ini to use:

php -c php.ini /wwwroot/yii/framework/yiic.php shell /wwwroot/blog/index.php

The commands above accomplish two tasks. First, the model command generates a model class file for each table in the blog database. Second, the crud commands generate the code needed by the CRUD operations for the Post and Comment models.

Tip: The command model * generates a model class for every table in the database. Sometimes, we probably don't want to do so (e.g. the database contains some irrelevant tables). In this case, we can create model classes one by one. For example, to create the User model, we can use the command model User. The model command also has some more advanced usages. For more details, execute help model command.

We can test the generated code by accessing the following URLs:

http://www.example.com/blog/index.php?r=post
http://www.example.com/blog/index.php?r=comment

Notice that the post and comment features implemented by the generated code are completely independent of each other. Also, when creating a new post or comment, we are required to enter information, such as author_id and create_time, which in real application should be set by the program. Don't worry. We will fix these problems in the next milestones. For now, we should be fairly satisfied as this prototype already contains most features that we need to implement for the blog application.

To prepare for the next milestones, let's take a closer look at the files generated by the above commands. All the files are generated under /wwwroot/blog/protected. For convenience, we group them into model files, controller files and view files:

• model files:

  • models/User.php contains the User class that extends from CActiveRecord and can be used to access the tbl_user database table;
  • models/Post.php contains the Post class that extends from CActiveRecord and can be used to access the tbl_post database table;
  • models/Tag.php contains the Tag class that extends from CActiveRecord and can be used to access the tbl_tag database table;
  • models/Comment.php contains the Comment class that extends from CActiveRecord and can be used to access the tbl_comment database table;
  • models/Lookup.php contains the Lookup class that extends from CActiveRecord and can be used to access the tbl_lookup database table;

• controller file:

  • controllers/PostController.php contains the PostController class which is the controller in charge of all CRUD operations about posts;
  • controllers/CommentController.php contains the CommentController class which is the controller in charge of all CRUD operations about comments;

• view files:

  • views/post/create.php is the view file that shows an HTML form to create a new post;
  • views/post/update.php is the view file that shows an HTML form to update an existing post;
  • views/post/view.php is the view file that displays the detailed information of a post;
  • views/post/index.php is the view file that displays a list of posts;
  • views/post/admin.php is the view file that displays posts in a table with administrative commands.
  • views/post/_form.php is the partial view file embedded in views/post/create.php and views/post/update.php. It displays the HTML form for collecting post information.
  • views/post/_view.php is the partial view file used by views/post/index.php. It displays the brief view of a single post.
  • views/post/_search.php is the partial view file used by views/post/admin.php. It displays a search form.
  • a similar set of view files are also generated for comment.

In order to understand better how the above files are used, we show in the following the workflow that occurs in the blog application when displaying a list of posts:

1. The user requests the URL http://www.example.com/blog/index.php?r=posts;
2. The entry script is executed by the Web server which creates and initializes an application instance to handle the request;
3. The application creates an instance of PostController and executes it;
4. The PostController instance executes the index action by calling its actionIndex() method. Note that index is the default action if the user does not specify an action to execute in the URL;
5. The actionIndex() method queries database to bring back the list of recent posts;
6. The actionIndex() method renders the index view with the post data.

Total 2 comments:

Your Comment: