Here, I'll take a look at the generator command, tspawn.
First, we must create a skeleton of the application before we can do anything else. We'll use the name blogapp again for our creation. Enter the following command from the command line. (In Windows, run from the TreeFrog Command Prompt).
| $ tspawn new blogapp
When you run, the directory tree including the application root directory at the top, configuration file (ini), and project files (pro) are generated. The directory is just one of the names you have seen before.
The following items will be generated as a directory.
- config – configuration files
- db - database file storage (SQLite)
- log – log files
- tmp – temparary directory, such as a file upload
The scaffold is a basic implementation that allows CRUD operations to take place. Included in the scaffold are; controller, model, source files for views, and project files (pro). The scaffold therefore forms a good basis on which to start a full-scale development.
In order to make a scaffold in the generator command, you need to define a table in the database in advance, and to describe the database information in the configuration file. Now, let's define a table.
See this example:
|> CREATE TABLE blog (id INTEGER PRIMARY KEY, title VARCHAR(20), body VARCHAR(200));|
If you want to use SQLite for the database, you should make the db database file in the application root directory. You can set the database information in the configuration file (database.ini). The generator command refers to the information that is set in the dev section.
Choices are as follows:
QDB2 : IBM DB2
QIBASE : Borland InterBase Driver
QMYSQL : MySQL Driver
QOCI : Oracle Call Interface Driver
QODBC : ODBC Driver
QPSQL : PostgreSQL Driver
QSQLITE : SQLite version 3 or above
In the case of SQLite a file path must be specified.
localhost in the case of blank
The default port if blank
|connectOptions||Connection options||For more information see Qt documents :
If the database driver is not included in the Qt SDK, you will not be able to access the database. If you have not yet built, you should incorporate the driver by reference to the FAQ. Alternatively, you can download the database driver from the download page, and then install it.
After the above, when you run the generator command (after the above steps), the scaffolding will be generated. Every command should be run from the application root directory.
|$ cd blogapp
$ tspawn scaffold blog
Database open successfully
In Brief: Define the schema in the database, and make the scaffolding with the generator command.
Relationship of model-name/controller-name and table name
The generator will generate class names determined on the basis of the table name. The rules are as the following.
| Table name Model name Controller name Sql object name
blog_entry → BlogEntry BlogEntryController BlogEntryObject
Notice that when the underscore is removed, the next character is capitalized. You may completely ignore any distinction between singular and plural word forms.
Here are the usage rules for the tspawn command.
|$ tspawn -h
usage: tspawn <subcommand> [args]
If you specify “controller”, “model”, or “sqlobject“ as a sub-command, you can generate ONLY “controller”, ONLY “model”, or ONLY “SqlObject”.
TreeFrog has no migration feature or other mechanism for making changes to and differential management of the DB schema. I think this is unimportant for the following reasons:
- If I had made a Migration function, users would face the extra learning cost.
- Those that are knowledgeable about SQL can enjoy the full functionality of dB operations.
- In TreeFrog, it is possible to regenerate only the ORM object classes when changing table.
→ (Unfortunately there might be some possibilities for affecting something to the model class…)
- I consider that there is little merit to framework-side differential management of SQL commands.
TreeFrog has a class naming and file naming convention. With the generator, class or file names are generated under the following terms and conditions.
Convention for Naming of Controllers
The class name of the controller is "table name + Controller". Always begin with an upper-case letter, do not use the underscore ('_') to separate words but capitalize the first letter after where the separator would be.
The following class names are good examples:
These files are stored in the controller’s directory. File names in that case will be something that you want to be in all lowercase; the class name plus the relevant extension (.cpp or .h).
Conventions for Naming Models
In the same manner as with the controller, model names should always begin with a capital letter, erase the underscore ('_') to separate words but capitalize the first letter after where the separator would be. For example, class names such as the following.
These files are stored in the models directory. As well as the controller, the file name will be something that you want all in lowercase. The model name is used, plus the file extension (.cpp or .h).
It does not convert the singular-plural form of words, as Rails does.
View Naming Conventions
Template files are generated with the file name "action name + extension" all in lower case, in the 'views/controller name" directory. The extension used depends on the template system.
Also, when you build the view, and then output the source file in views/_src directory they are converted to C++ code templates. When these are compiled, a shared library view is created.
CRUD covers the four major functions found in a Web application. The name comes from taking the initial letters of "Create (generate)," "Read (Read)", "Update (update)", and "Delete (Delete)".
When you create a scaffolding, the generator command generates the naming code in the next.
CRUD Correspondence Table
About the T_CONTROLLER_EXPORT Macro
The controller class that you created in the generator, will have added a macro called T_CONTROLLER_EXPORT.
In Windows, the controller is a single DLL file, but in order to be available from outside the classes and functions of these, we need to define it with a keyword __declspec called (dllexport). The T_CONTROLLER_EXPORT macro is then replaced with this keyword.
However, nothing is defined in the T_CONTROLLER_EXPORT in Linux and Mac OS X installations, because a keyword is unnecessary.
In this way, the same source code is used, and you are thus able to support multiple platforms.