(For more resources related to this topic, see here.)
Step 1 – Planning the workflow
When you'll be writing a real application, you should start with the requirements to application functionality. For the blog example, they described in the Getting Started: Requirements Analysis section, at the very beginning of the tutorial. Direct URL is http://www.yiiframework.com/doc/blog/1.1/en/start.requirements.
After you have written all the desired features, you basically start implementing them one by one. Of course, in serious software development there's a lot of gotchas included but overall it's the same.
Blog example is a database driven application, so we need to prepare a database schema beforehand. Here's what they came up with for the blog demo.
This image is a verbatim copy from the blog example demo. Note that there are two links missing. The posts table have tags field which is the storage area for tags written in raw and is not a foreign key to tags table. Also author field in comment should really be the foreign key to user table. Anyways, we'll not cover the actual database generation, and suggest you can do it yourself. The blog tutorial at the Yii website has all the relevant instructions addressed to total newbies.
Next in this article we will see how easy it is with Yii to get a working user interface by which one will be able to manipulate our database.
Step 2 – Linking to the database from your app
Once you design and physically create, the database in some database management system like MySQL or maybe SQLite, you are ready to configure your app to point to this database. The skeleton app generated by the ./yiic webapp command needs to be configured to point to this database. To do this, you need to set a db component in the main config file located at protected/config/main.php. There is a section that contains an array of components. Below is the setup for a MySQL database located at the same server as the web application itself. You will find a commented-out template for this already present when you generate your app.
/* other components */
'connectionString' => 'mysql:host=localhost;dbname=DB_NAME,
'emulatePrepare' => true,
'username' => YOUR_USERNAME,
'password' => YOUR_PASSWORD,
'charset' => 'utf8',
/* other components */
This is a default component having a class CDbConnection and is used by all of our ActiveRecord design patterns which we will create later. As with all application components, all configuration parameters corresponds to the public properties of the component's class, so, you can check the API documentation for details.
By the way, you really want to understand more about the main application config. Read about it in the Definitive Guide to Yii at the official website, at Fundamentals | Application | Application Configuration. Direct URL is http://www.yiiframework.com/doc/guide/1.1/en/basics.application#application-configuration.
Just remember that all configuration parameters are just properties of CWebApplication object, which you can read about it the API documentation, direct URL is
Step 3 – Generating code automatically
Now that we have our app linked up to a fully built database, we can start using one of Yii's greatest features: automatic code generation. To get started, there are two types of code generation that are necessary:
- Generate a model classes based on the tables in your database
- Run the CRUD generator that takes a model and sets up a corresponding controller and set of views for basic listing, creating, viewing, updating and deleting from the table
There are two ways to go about automatic code generating. Originally, there was only the yiic tool used earlier to create the skeleton app. For the automatic code generation features, you would use yiic shell index.php command, which would bring up a command-line interface where you could run subcommands for modeling and scaffolding.
$ /usr/local/yii/framework/yiic shell index.php
Yii Interactive Tool v1.1 (based on Yiiv1.1.13)
Please type 'help' for help. Type 'exit' to quit.
>> model Post tbl_post
The following model classes are successfully generated:
If you have a 'db' database connection, you can test these models now
>> crud Post
As you can see, this is a quick and easy way to perform the model and crud actions. The model command produces just two files:
- For your actual model class
- For unit tests
The crud command creates your controller and view files.
Console tools may be the preferred option for some, but for developers who like to use graphical tools, there is now solution for this, called Gii.
To use Gii, it is necessary to turn it on in the main config file: protected/config/main.php. You will find the template for it already present, but it is commented out by default. Simply uncomment it, set your password, and decide from what hosts it may be accessed. The configuration looks like this:
// If removed, Gii defaults to localhost only.
// Edit carefully to taste.
// For development purposes,
// a wildcard will allow access from anywhere.
Once Gii is configured, it can be accessed by navigating to the app URL with ?r=gii after it. For example, http://www.example.com/index.php?r=gii. It will begin with a prompt asking for the password set in the config file. Once entered, it will display a list of generators. If the database is not set in the config file, you will see an error when you attempt to use one.
The first most basic generator in Gii is the model generator. It asks for a table name from the database and a name to be used for the PHP class.
Note that we can specify a table name prefix which will be ignored when generating the model class name. For instance, the blog demo's user table is tbl_user, where the tbl_ is a prefix. This feature exists to support some setups, especially common in shared hosting environments, where a single database holds tables for several distinct applications. In such an environment, it's a common practice to prefix something to names of tables to avoid getting into naming conflict and easily find tables relevant to some specific application. So, as this prefixes don't mean anything in the application itself, Gii offers a way to automatically ignore them. Model class names are being constructed from the remaining table names by the obvious rules:
- Underscores are converted to uppercasing the next letter
- The first letter of the class name is being uppercased as well.
The first step in getting your application off the ground is to generate models for all the entity tables in your database. Things like bridge tables will not need models, as they simply relate two entities to one another, rather than actually being a distinct thing. Bridge tables are being used for generating relations between models, expressed in the relations method in model class.
For the blog demo, basic models are User, Post, Comment, Tag, and Lookup.
The second phase of scaffolding is to generate the CRUD code for each of these models. This will create a controller and a series of view templates. The controller (for example. PostController) will handle routing to actions related to the given model. The view files represent everything needed to list and view entities, as well as the forms needed to create and update individual entities.
In this article we created an application by following a series of steps such as planning the workflow, linking to the database from your app, and generating code automatically.
Resources for Article :
- Database, Active Record, and Model Tricks [Article]
- Building multipage forms (Intermediate) [Article]
- Creating a Recent Comments Widget in Agile [Article]