Note
Inside the code bundle that comes with this book, you will find the acceptance test definitions for the CRUD UI we have been building in this chapter. This was not included in the text for brevity. Run the following command:
$ ./cept run acceptance
This command will produce an output as shown in the following screenshot:
Note that we haven't manually written a single line of production code to make these tests pass (with the exception of the layout). Also, given that all the possible preparations were done already, the next time we need to make such a CRUD UI, we will just need to fill in six fields and click on two buttons, and we'll have it.
By going to the /services route, we get a nice table, filled to the brim with features:
Each record is represented by a row in the table. This tabular UI has pagination with the default page size of 20 lines (this can be a problem if you run acceptance tests too many times without cleaning the database upon deploying or redeploying a target). Also, it has fields at the top of the table to filter rows by the field values, as shown in the following screenshot:
Finally, the last column in each row contains three iconic buttons: one with an eye, one with a pencil, and one with a trash can. They correspond to the view, update, and delete actions, respectively. The view action renders a nice list of fields and their values for the selected record.
The view route will be /services/view?id=:id, where :id is the primary key of the Service record in the database. In there, you'll see the Update and Delete buttons too.
If you click on the Update button either from the list UI or from the view UI, you get a form to edit the fields of the selected record.
The update route will be /services/update?id=:id, with the same rules as that of the view route. This form is absolutely identical to the form where we create a new record, which we will see in the following chapters.
If you click on the Delete button either from the list UI or from the view UI, you will get a delete confirmation, which, as we saw earlier in this chapter, is potentially dangerous in nature:
If you accept the deletion, the table will be refilled via AJAX. If you have JavaScript disabled, you'll get no delete behavior at all because /services/delete?id=:id is configured to be accessible only by POST requests.
If you click on the big green Create Service Record button, you'll get a form to enter data for a new ServiceRecord model. The create route will be /services/create. This form has built-in client-side validation. It won't allow you to submit the form if there are errors in the input data.
All of this UI is based on the Twitter Bootstrap UI framework plus some Yii-specific JavaScript code.