pop-kettle
The popphp/pop-kettle component a CLI-based help script called kettle
. It allows
a user to quickly build the scaffolding for an application and manage database functions
from the command line. It is available as of version 4.0.1 of the Pop PHP Framework.
Installation
Install it directly into your project:
composer require popphp/pop-kettle
Or, include it in your composer.json file:
{
"require": {
"popphp/pop-kettle": "^1.6.2"
}
}
Basic Use
As of version 4.0, the Pop PHP Framework incorporates a CLI-based help script called
kettle
. It allows a user to quickly build the scaffolding for an application and
manage database functions from the command line.
Application Scaffolding
While a particular application structure isn’t strictly enforced, applications built with the
pop-kettle
component follow a fairly straight-forward application structure. All of these
files and folders, outside of the kettle
script, will be created for you if they do not already
exist. Please note, the kettle
script file is kept in the main root level, and should be set to be
executable.
app/
config/
src/
view/
database/
migrations/
seeds/
public/
script/
kettle
The app/
folder contains the main set of folders and files that make the application work, like config/
,
src/
and view/
. The database/
folder contains the database migrations
and seeds
folders.
The public/
folder is the web document root that contains the main index.php
front controller script file
that runs the main web application. The script/
folder contains the main script that would run the console
version of the application.
The kettle
script allows you to run a simple command that will wire up some basic application files and folders
to get started. By running the following command, you can set up the basic files and folders required to run
an application:
$ ./kettle app:init [--web] [--api] [--cli] <namespace>
The <namespace>
parameter is the namespace of your application, for example MyApp
.
The optional parameters of --web
, --api
, and --cli
will create the related files
and folders to run the application as a normal web application, an API-driven web
application, a CLI-driven console application or any combination thereof.
After the application files and folders are copied over, you will be asked if you would like to configure a database. Follow those steps to configure a database and create the database configuration file.
A Note About Folder Structure
Once the script creates the starter files, you will see certain folders created based on the configuration
options used. If you used no options, or just the --web
option, it will create the files and folders for
a basic web application:
app/config
app/src
app/src/Http
app/src/Http/Controller
app/view
public
If you use the --cli
option, it will create the files and folders for a basic console application:
app/config
app/src
app/src/Console
app/src/Console/Controller
script
If you use both --web
and --cli
options, it will create both sets of files and folders:
app/config
app/src
app/src/Console
app/src/Console/Controller
app/src/Http
app/src/Http/Controller
app/view
public
script
If you use all 3 options together, --web
, --api
and --cli
, it will create both sets of files and folders,
but it will break the Http
namespace into 2 separate namespaces for the public-facing web application as well
as the API web application:
app/config
app/src
app/src/Console
app/src/Console/Controller
app/src/Http
app/src/Http/Controller
app/src/Http/Api
app/src/Http/Api/Controller
app/src/Http/Web
app/src/Http/Web/Controller
app/view
public
script
The idea here being to keep both access points of the web application separate. So, for example, if a user’s
browser requests http://localhost:8000/
, it would render an HTML page. And if an API request is sent to
http://localhost:8000/api
, it would render a appropriate API response, like a set of JSON data.
Database Management
Once the application is initialized, you can manage the database, or multiple databases, by using the
db
and migrate
commands. If you don’t pass anything in the optional [<database>]
parameter,
it will default to the default
database.
./kettle db:install [<database>] Install the database (Runs the config, test and seed commands)
./kettle db:config [<database>] Configure the database
./kettle db:test [<database>] Test the database connection
./kettle db:create-seed <seed> [<database>] Create database seed class
./kettle db:seed [<database>] Seed the database with data
./kettle db:reset [<database>] Reset the database with original seed data
./kettle db:clear [<database>] Clear the database of all data
./kettle migrate:create <class> [<database>] Create new database migration class
./kettle migrate:run [<steps>] [<database>] Perform forward database migration
./kettle migrate:rollback [<steps>] [<database>] Perform backward database migration
./kettle migrate:reset [<database>] Perform complete rollback of the database
Installing the Database
The command to install the database is a convenient combination the db:config
, db:test
and db:seed
commands.
Running the db:install
command will prompt you to enter the database configuration parameters. Once those are entered,
it will test the database, and on a successful test, it will run the seed command and install any initial data it finds
in the seeds folder. The db:install
command is what is run at the end of the app:init
command if you answer ‘Y’
the question “Would you like to configure a database?”
Seeding the Database
You can seed the database with data in one of two ways. You can either utilize a SQL file with the extension .sql
in the /database/seeds/<database>
folder or you can write a seeder class using PHP. To get a seed started,
you can run:
$ ./kettle db:create-seed <seed> [<database>]
Where the <seed>
is either the base class name of the seeder class that will be created, or the name of a
SQL file (i.e., seed.sql
) that will be populated later with raw SQL by the user. The template seeder class
will be copied to the /database/seeds/<database>
folder:
<?php
use Pop\Db\Adapter\AbstractAdapter;
use Pop\Db\Sql\Seeder\AbstractSeeder;
class MyFirstSeeder extends AbstractSeeder
{
public function run(AbstractAdapter $db)
{
}
}
From there, you can populate your SQL file with the raw SQL needed, or you can fill in the run()
method in
the seeder class with the SQL you need to seed your data:
<?php
use Pop\Db\Adapter\AbstractAdapter;
use Pop\Db\Sql\Seeder\AbstractSeeder;
class DatabaseSeeder extends AbstractSeeder
{
public function run(AbstractAdapter $db)
{
$sql = $db->createSql();
$sql->insert('users')->values([
'username' => 'testuser',
'password' => '12test34',
'email' => 'test@test.com'
]);
$db->query($sql);
}
}
Then running the following command will execute any SQL in any SQL files or any of the SQL in the seeder classes:
$ ./kettle db:seed
Database Migrations
You can create the initial database migration that would modify your database schema as your application grows by running the command:
$ ./kettle migrate:create <class> [<database>]
Where the <class>
is the base class name of the migration class that will be created. You will see your new
migration class template in the /database/migrations/<database>
folder:
<?php
use Pop\Db\Sql\Migration\AbstractMigration;
class MyFirstMigration5dd822cdede29 extends AbstractMigration
{
public function up()
{
}
public function down()
{
}
}
From there, you can populate the up()
and down()
with the schema to modify your database:
<?php
use Pop\Db\Sql\Migration\AbstractMigration;
class MyFirstMigration5dd822cdede29 extends AbstractMigration
{
public function up()
{
$schema = $this->db->createSchema();
$schema->create('users')
->int('id', 16)->increment()
->varchar('username', 255)
->varchar('password', 255)
->varchar('email', 255)
->primary('id');
$schema->execute();
}
public function down()
{
$schema = $this->db->createSchema();
$schema->drop('users');
$schema->execute();
}
}
You can run the migration and create the users
table by running the command:
$ ./kettle migrate:run
And you can rollback the migration and drop the users table by running the command:
$ ./kettle migrate:rollback
Running the Web Server
The pop-kettle
component also provides a simple way to run PHP’s built-in web-server, by running the command:
$ ./kettle serve [--host=] [--port=] [--folder=]
This is for development environments only and it is strongly advised against using the built-in web server in a production environment in any way.
Accessing the Application
If you have wired up the beginnings of an application, you can then access the default routes in the following ways.
Assuming you’ve started the web server as described above using ./kettle serve
, you can access the web application
by going to the address http://localhost:8000/
in any web browser and seeing the default index HTML page.
If you want to access the API application, the default route for that is http://localhost:8000/api and you can access it like this to see the default JSON response:
$ curl -i -X GET http://localhost:8000/api
And, if you cd script
, you’ll see the default CLI application that was created. The default route available
to the CLI application is the help route:
$ ./myapp help
Hooking into Kettle
If you need to hook into the Kettle helper application, you can do that with the provided kettle.inc.php
file.
The file is included right after the creation of the $app
object, so you will have access to the application
object. In this file you can add any additional runtime requirements, configurations or routes directly to the
Kettle helper application.
Using on Windows
Most UNIX-based environments should recognize the main kettle
application script as a PHP script and run it
accordingly, without having to explicitly call the php command and pass the script and its parameters into it.
However, if you’re on an environment like Windows, depending on your exact environment set up, you will most
likely have to prepend all of the command calls with the php
command, for example:
C:\popphp\pop-kettle>php kettle help