Work In Progress

This book is currently work in progress. Some sections are not yet written. Thank you for your understanding!

Controllers

The API controllers all extend from the core \Joomla\CMS\MVC\Controller\ApiController class. The API controllers will, by default, implement CRUD (Create, Read, Update, Delete). Do note that Read in this context means both returning a single item and returning a list of items.

At a minimum, you need to override the $contentType and $default_view properties.

The $contentType property is used as the context to the onGetApiAttributes and onGetApiRelation events. The former is used to modify the data of the JSON response. The latter is used to add related data to the JSON response.

[Note]Note

Unfortunately, the content type is a very bad choice for context in these events because it's not unique across components and the component's name is not given in the event arguments. For example, the type groups is already duplicated in the core, for com_fields and com_users.

For this reason, you may want to provide your extension's $contentType in the format com_example.item, i.e. prefix your content type with the name of your component and a dot. It's a far cry from being intuitive, especially since consumers will have to remove the prefix to find out the API route which gives them access to this content type, but at least it provides a valid, unique context for the events.

In most cases you do not want to change the displayItem (read one), displayList (read many), delete (remove), add (create), and edit (update) methods. When you do, it's mostly so you can set a filter state in the view's Model. Joomla's core components do that a lot in their api application part.

You will most likely need to override one or more of the following methods for most real world components:

  • allowEdit. Is the current user allowed to edit (update) the item? By default, it only checks the core.edit privilege of the current user for your component. The method is passed the data and the table's primary key in case you need to do more fine grained access control. For example, a forum component will very reasonably only allow the user who posted a specific post and the forum administrators to edit a post, not any random person who can post into the forum.

  • allowAdd. Is the current user allowed to add (create) a new item? By default, it only checks if the currently logged in user has the core.create privilege for your component or they have the core.create privilege in any categories which belong to your component (assuming you are integrating with Joomla's com_categories). The method is passed the data to be created in case you need to perform more fine-grained access control. For example, a helpdesk component would only allow the user who owns a support ticket and the support staff to post replies to a specific ticket. The view handling replies would check the ticket ID in the data to determine if this is the case before allowing a new post to be created.

  • preprocessSaveData. This is executed after allowEdit and allowAdd, but before handling tags and saving the data into the database. This is your last chance to make any modifications to the data before committing it to the database. For example, you may want to perform additional validation and cleanup of HTML content, or you may want to automatically fill in missing information which would cause a validation error when the Model tries to save the data.