...
This step is very similar to the previous one on adding the pagination. We are going to add a new type parameter in the whole component stack; the main difference with the offset case is that the user will pick a Content Type in a drop-down list instead of just using the Next/Previous links in the page.
...
Of course, the end user is not supposed to tweak the URI to filter by Content Type. To provide a usable interface, we will add a a drop-down list where he they can choose a Content Type to only get the corresponding list. Again, this is done server side by modifying the Controller to fetch the list of Content Types and Content Type Groups with the Content Type Service. Once this is done, the types and the groups can be passed to the Twig template to build a drop-down list in the following way:
...
The only remaining feature is now to take into account the user interaction on the added drop-down list. The view is responsible for that and it will basically subscribe to the change DOM event on the list and will fire the the navigateTo event like we did in the offset case:
...
Basically, when the user selects a value in the drop-down list, the view fires the navigateTo event to navigate to the eZConfListOffsetTypeIdentifier route with the corresponding Content Type identifier and the offset set to 0. The view service is still handling this event and takes the user to the corresponding page in the application.
| Tip | ||
|---|---|---|
| ||
And that's it! We now have a working interface to navigate through Content with a flat list that can be filtered by Content Type. The resulting code can be seen in the |