Gii automatic code generation

Gii is implemented in a modular manner and must be used in an existing Yii application. To use Gii, first change the application configuration as follows 1. use Gii

Gii is implemented in a modular manner and must be used in an existing Yii application. To use Gii, first change the application configuration as follows:

Return array (
......
'Modules' => array (
'Giii '=> array (
'Class' => 'system. gii. GiiModule ',
'Password' => 'Enter the password here ',
// 'Ipfilters '=> array (... IP list ...),
// 'Newfilemode' => 0666,
// 'Newdirmode' => 0777,
),
),
);

Above, we declare a module named gii, whose class is GiiModule. We also set a password for this module. when we access Gii, there will be an input box requesting this password.

For security reasons, by default, only local access to Gii is allowed. To allow other trusted machines to access it, we need to configure the GiiModule: ipFilters attribute as shown above.

Because Gii will generate and save new files to the application, we need to ensure that the Web server process has the permission to do so. The above GiiModule: newFileMode and GiiModule: newDirMode attributes control how to generate new files and directories.

Note: Gii is mainly used as a development tool. Therefore, you should only install it on the development machine. Because it can generate new PHP files in applications, we should pay enough attention to security issues (such as setting passwords and IP address filtering ).

Now you can use URL http: // hostname/path/to/index. php? R = gii is accessing Gii. Assume that http: // hostname/path/to/index. php is the URL used to access the Yii application.

If the Yii application uses a URL in path format (view URL management), we can access gii through URL http: // hostname/path/to/index. php/Gii. We may need to add the following URL rules before the existing URL rules:

'Components' => array (
......
'Urlmanager' => array (
'Urlformat' => 'path ',
'Rules' => array (
'Giii '=> 'giii ',
'Giii/ '=> 'Giii/ ',
'Giii/ /'=> 'Giii/ /',
... Existing rules...
),
),
)

Gii has some default code generators. Each code generator is responsible for generating specific types of code. For example, the controller generator generates a controller class and some action view scripts. The model generator generates a ActiveRecord class for the specified data table.

The basic process for using a generator is as follows:

Go to the generator page;

Enter the input box for the specified code generation parameter. For example, to use Module Generator to create a new module, you must specify the Module ID;

Click the Preview button to Preview the code to be generated. You will see a table listing the files to be generated. You can click any file to preview the code;

Click Generate to Generate these code files;

View the code generation log.

2. extended Gii

Although the default Gii code generator can generate very powerful code, we often want to customize them or create a new one to suit our taste and needs. For example, we want to make the generated code a style we like, or we want the code to support multiple languages. All of these can be easily implemented in Gii.

You can expand Gii in two ways: Customize the code template of an existing code generator and compile a new code generator.
Code generator architecture

A code generator is stored in a directory. the directory name is considered the name of the generator. A directory usually consists of the following content:

Model/the model generator root folder
ModelCode. php the code model used to generate code
ModelGenerator. php the code generation controller
Views/containing view scripts for the generator
Index. php the default view script
Templates/containing code template sets
Default/the 'default' code template set
Model. php the code template for generating model class code

Builder search path

Gii searches for available generators in the directory specified by the GiiModule: generatorPaths attribute. When customization is required, we can make the following configuration in the application configuration file,

Return array (
'Modules' => array (
'Giii '=> array (
'Class' => 'system. gii. GiiModule ',
'Generatorpaths '=> array (
'Application. gii', // a path alias
),
),
),
);

The above configuration tells Gii to find the generator in the directory where the alias is application. gii and the default location is system. gii. generators.

It is also possible to have a generator with the same name in different search paths. In this case, the generator that appears first in the directory specified by GiiModule: generatorPaths has priority.
Custom code template

This is the easiest and most common way to expand Gii. We use an example to describe how to customize a code template. Suppose we want to customize the code generated by the model generator.

Create a directory named protected/gii/model/templates/compact. The model here means that we will override the default model generator. Templates/compact means that we will add a new code template set named compact.

Then, we add application. gii to GiiModule: generatorPaths in application configuration. As shown above.

Open the model code generator page. Click the Code Template input box. We should see a drop-down list that contains the newly created template directory compact. However, if we select this template to generate code, we will see an error. This is because we have not put any actual code template files in the new compact template set.

Copy the file framework/gii/generators/model/templates/default/model. php to protected/gii/model/templates/compact. If we try to generate a compact template again, we will succeed. However, the generated code is no different from the code generated using the default template set.

Now it's time to do some real work. Open the file protected/gii/model/templates/compact/model. php to edit it. Remember that this file will be used as a view file, which means it can contain PHP expressions and statements. Let's change the template so that the attributeLabels () method in the generated code uses Yii: t () to translate attribute tags:

Public function attributeLabels ()
{
Return array (
$ Label):?>
Yii: t ('application', '$ label'), \ n ";?>

);
}

In each code template, we can access some predefined variables, such as $ labels in the preceding example. These variables are provided by the corresponding code generator. Different code generators may provide different variables in their code templates. Read the description in the default code template carefully.
Create a new generator

In this sub-section, we show how to create a new generator that can generate a new widget class.

We first create a directory named protected/gii/widget. Under this directory, we will create the following files:

WidgetGenerator. php: contains the WidgetGeneratorcontroller class. This is the entry point of the widget generator.

WidgetCode. php: contains the WidgetCodemodel class. This class has the main logic for code generation.

Views/index. php: the view script showing the code generator input form.

Templates/default/widget. php: the default code template for generating a widget class file.

Creating WidgetGenerator. php

The WidgetGenerator. phpfile is extremely simple. It only contains the following code:

Class WidgetGenerator extends CCodeGenerator
{
Public $ codeModel = 'application. gii. widget. widgetcode ';
}

N the above code, we specify that the generator will use the model class whose path alias is application. gii. widget. widgetCode. the WidgetGeneratorclass extends from CCodeGeneratorwhich implements a lot of functionalities, including the controller actions needed to coordinate the code generation process.
Creating WidgetCode. php

The WidgetCode. phpfile contains the WidgetCodemodel class that has the main logic for generating a widget class based on the user input. in this example, we assume that the only input we want from the user is the widget class name. our WidgetCodelooks like the following:

Class WidgetCode extends CCodeModel
{
Public $ className;

Public function rules ()
{
Return array_merge (parent: rules (), array (
Array ('classname', 'required '),
Array ('classname', 'match', 'pattern' => '/^ \ w + $ /'),
));
}

Public function attributeLabels ()
{
Return array_merge (parent: attributeLabels (), array (
'Classname' => 'widget Class name ',
));
}

Public function prepare ()
{
$ Path = Yii: getPathOfAlias ('application. components. '. $ this-> className).'. php ';
$ Code = $ this-> render ($ this-> templatepath. '/widget. php ');

$ This-> files [] = new CCodeFile ($ path, $ code );
}
}

The WidgetCodeclass extends from CCodeModel. like a normal model class, in this class we can declare rules () and attributeLabels () to validate user inputs and provide attribute labels, respectively. note that because the base class CCodeModelalready defines some rules and attribute labels, we shocould merge them with our new rules and labels here.

The prepare () method prepares the code to be generated. its main task is to prepare a list of CCodeFileobjects, each of which represent a code file being generated. in our example, we only need to create one CCodeFileobject that represents the widget class file being generated. the new widget class will be generated under the protected/componentsdirectory. we call CCodeFile: rendermethod to generate the actual code. this method already des the code template as a PHP script and returns the echoed content as the generated code.
Creating views/index. php

Having the controller (WidgetGenerator) and the model (WidgetCode), it is time for us to create the view views/index. php.

Widget Generator

BeginWidget ('ccodeform', array ('model' => $ model);?>


LabelEx ($ model, 'classname');?>
TextField ($ model, 'classname', array ('size' => 65);?>

Widget class name must only contain word characters.

Error ($ model, 'classname');?>


EndWidget ();?>

In the above, we mainly display a form using the CCodeForm widget. In this form, we display the field to collect the input for the classNameattribute in WidgetCode.

When creating the form, we can exploit two nice features provided by the CCodeForm widget. One is about input tooltips. The other is about sticky inputs.

If you have tried any default code generator, you will notice that when setting focus in one input field, a nice tooltip will show up next to the field. this can easily achieved here by writing next to the input field a divwhose CSS class is tooltip.

For some input fields, we may want to remember their last valid values so that the user can save the trouble of re-entering them each time they use the generator to generate code. an example is the input field collecting the controller base class name default controller generator. these sticky fields are initially displayed as highlighted static text. if we click on them, they will turn into input fields to take user inputs.

In order to declare an input field to be sticky, we need to do two things.

First, we need to declare a stickyvalidation rule for the corresponding model attribute. For example, the default controller generator has the following rule to declare that baseClassand actionsattributes are sticky:

Public function rules ()
{
Return array_merge (parent: rules (), array (
......
Array ('baseclass, actions', 'sticky '),
));
}

Second, we need to add a CSS class named stickyto the container divof the input field in the view, like the following:


... Input field here...


Creating templates/default/widget. php

Finally, we create the code template templates/default/widget. php. as we described earlier, this is used like a view script that can contain in PHP expressions and statements. in a code template, we can always access the $ thisvariable which refers to the code model object. in our example, $ thisrefers to the WidgetModelobject. we can thus get the user-entered widget class name via $ this-> className.



Class ClassName;?> Extends CWidget
{
Public function run ()
{

}
}

This concludes the creation of a new code generator. We can access this code generator immediately via the URL http: // hostname/path/to/index. php? R = gii/widget.
Gii is implemented in a modular manner and must be used in an existing Yii application. To use Gii, first change the configuration of the application. the following Gii is implemented in a modular manner and must be used in an existing Yii application. To use Gii, first change the application configuration as follows: