Back in Chapter 2, Making a Custom Application with Yii 2, we cut some corners and implemented only part of the functionality of our already rudimentary example CRM application. This chapter will conclude the example.
Our goal here will be to finish the CRUD for the customer model and to have in the end an efficient user interface to filter the recorded customers.
We'll learn to use arguably the most complex widget among the ones shipped together with the Yii framework, the GridView widget. But the GridView widget is there only to present records from the database; we will also make the form to actually enter the customer models into the database, utilizing the ActiveForm widget.
In this chapter, we'll discuss the following topics:
- The widgets concept in general
- The structure of the GridView widget, especially its concept of columns
- The built-in features of the GridView widget
- Making custom columns via the GridView widget in two ways
- Implementing sorting and filtering inside the GridView widget for custom columns
In Chapter 2, Making a Custom Application with Yii 2, we tried pretty hard to decouple ourselves from the framework to continue being able to test and extend our application later, when we get some real business rules apart from the mindless CRUD interface. Of course, this is a lot of additional work, as we're essentially placing an additional level of abstraction over the active records.
This is not idiomatic Yii code. Yii provides you with a really robust and useful API for a lot of areas but, at the same time, it tries really hard to couple you to both its data and presentation layer, which is trouble all the way down the road.
Most probably, you'll see such a code out in the wild a lot of times when maintaining Yii-based applications, and, hence, we decided to show you how the web application development is done the Yii way, as opposed to using the Yii way shown in Chapter 2, Making a Custom Application with Yii 2. We'll call the active records directly from the controllers and pass them directly to our views. Most of our code will be autogenerated and left untouched. We basically throw away the domain and application layers from our application. Let's see how it'll look and feel this way.
As we already have the active records in our data layer, such a change will cost us nothing, because we would be generating them anyway. We will also not write any automatic tests, relying only on looking visually at our pages being developed. This way, we'll get a working application too, and we will get it even faster than before.