In this chapter we’ll take a look at the generator command with the short name: tspawn.
Generate a Skeleton
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 it from the TreeFrog Command Prompt):
$ tspawn new blogapp
When you run this command, the directory tree will then include the application root directory at the top. The configuration file (ini) and the project files (pro) will be generated, too. The directory is just one of the names you have already 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
Generate a Scaffold
The scaffold contains a basic implementation allowing CRUD operations to take place. The scaffold includes the following components: controller, model, source files for views, and project files (pro). Therefore, the scaffold forms a good basement on which you can start to establish your full-scale development.
In order to generate a scaffold with the generator command tspawn, you need to define a table in the database in advance and to set the database information in the configuration file (database.ini).
Now, let’s define a table. See the following example:
> CREATE TABLE blog (id INTEGER PRIMARY KEY, title VARCHAR(20), body VARCHAR(200));
If you want to use SQLite for your database, you should make the database file in the application root directory. You can set the database information in the configuration file. The generator command refers to the information that is set in the dev section.
[dev] driverType=QMYSQL databaseName=blogdb hostName= port= userName=root password=root connectOptions=
|driverType||Driver name||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
|databaseName||Database name||In the case of SQLite a file path must be specified.
|hostName||Host name||localhost in the case of blank|
|port||Port number||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 won’t be able to access the database. If you haven’t built yet, you should setup the driver. Alternatively, you can download the database driver from the download page, and then install it.
When you run the generator command (after the above mentioned steps), the scaffolding will be generated. Every command should be running from the application root directory.
$ cd blogapp $ tspawn scaffold blog driverType: QMYSQL databaseName: blogdb hostName: Database open successfully created controllers/blogcontroller.h created controllers/blogcontroller.cpp ：
In brief: Define the schema in the database and make us the generator command for the scaffolding.
Lists files and directories.
$ tree . ├── CMakeLists.txt ├── appbase.pri ├── blogapp10.pro ├── cmake │ ├── CacheClean.cmake │ └── TargetCmake.cmake ├── config │ ├── application.ini │ ├── cache.ini │ ├── database.ini │ ├── development.ini │ ├── internet_media_types.ini │ ├── logger.ini │ ├── mongodb.ini │ ├── redis.ini │ ├── routes.cfg │ └── validation.ini ├── controllers │ ├── CMakeLists.txt │ ├── applicationcontroller.cpp │ ├── applicationcontroller.h │ ├── blogcontroller.cpp │ ├── blogcontroller.h │ └── controllers.pro ├── db │ └── dbfile ├── helpers │ ├── CMakeLists.txt │ ├── applicationhelper.cpp │ ├── applicationhelper.h │ └── helpers.pro ├── lib ├── log ├── models │ ├── CMakeLists.txt │ ├── blogservice.cpp │ ├── blogservice.h │ ├── models.pro │ ├── mongoobjects │ ├── objects │ │ ├── blog.cpp │ │ └── blog.h │ └── sqlobjects │ └── blogobject.h ├── plugin ├── public │ ├── css │ ├── images │ └── js ├── script ├── sql ├── test ├── tmp └── views ├── CMakeLists.txt ├── _src │ └── _src.pro ├── blog │ ├── create.erb │ ├── index.erb │ ├── save.erb │ └── show.erb ├── layouts ├── mailer ├── partial └── views.pro
Relationship of Model-Name/Controller-Name and Table Name
The generator will create class names determined on the basis of the table name. The rules are as follows:
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] Type 'tspawn --show-drivers' to show all the available database drivers for Qt. Type 'tspawn --show-driver-path' to show the path of database drivers for Qt. Type 'tspawn --show-tables' to show all tables to user in the setting of 'dev'. Type 'tspawn --show-collections' to show all collections in the MongoDB. Available subcommands: new (n) <application-name> scaffold (s) <table-name> [model-name] controller (c) <controller-name> action [action ...] model (m) <table-name> [model-name] helper (h) <name> usermodel (u) <table-name> [username password [model-name]] sqlobject (o) <table-name> [model-name] mongoscaffold (ms) <model-name> mongomodel (mm) <model-name> websocket (w) <endpoint-name> api (a) <api-name> validator (v) <name> mailer (l) <mailer-name> action [action ...] delete (d) <table-name, helper-name or validator-name>
If you specify “controller”, “model”, or “sqlobject” as a sub-command, you can generate ONLY “controller”, “model” and “SqlObject”.
TreeFrog has no migration feature or other mechanism for making changes to and differential management of the DB schema. Therefore, using a migration tool for DB schema is recommended if necessary.
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”. The controller’s class name always begins with an upper-case letter, do not use the underscore (‘_’) to separate words, but capitalize the first letter (camelcase) after where the separator would be.
The following class names are good examples to understand the here described convention:
These files are stored in the controller’s directory. File names inside the that folder will be all in 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 all in lowercase. The model name is used plus the file extension (.cpp or .h). Unlike in Rails, we don’t use convertion of singular and plural form of words here.
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, which is used here, depends on the template system. Also, when you build the view and then output the source file in views/_src directory, you will notice that these files have been all converted to C++ code templates. When these files are compiled, a shared library view will be created, too.
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 as follows:
CRUD Correspondence Table
About the T_CONTROLLER_EXPORT Macro
The controller class that you have 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 the classes and functions of these available from outside, 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.