Component Creator Event Triggers - Proposed Solution
This document is a white paper detailing the proposed implementation of a new “Triggers” solution in Component creator. It aims to address the fact that many developers need to add custom functionality to their components and when they do, they either lose the ability to update the component with changes made in Component Creator, or they will need to keep track of their custom changes and re-apply them after updating Component Creator.
You can contribute to the discussion about this issue on GitHub.
Overrides versus Event Triggers
We have identified two approaches to solving this issue. One is to develop into the core of components generated in Component Creator the option to not only override Views, but also Models and Controllers. This would be a very powerful solution, but would require strong knowledge of developers to override the correct methods. It would also still suffer from the problem where making changes in Component Creator would not be reflected in the overrides.
For this reason, we are instead proposing to implement event triggers as suggested by GitHub user @gdpodesta.
Event Triggers
Event triggers are actions (executing php code) that will be “triggered” on events happening in the Component Creator code. It will use the Joomla plug-in technology.
We propose the following triggers to implemented:
- $row = onTable{TableSingularName}BeforeAdd($row)
- $row = onTable{TableSingularName}AfterAdd($row)
- $row = onTable{TableSingularName}BeforeUpdate($row)
- $row = onTable{TableSingularName}AfterUpdate($row)
- bool = onTable{TableSingularName}BeforeDelete($id)
- bool = onTable{TableSingularName}AfterDelete($id)
A couple of things to note here.
- This is just for illustration purpose, it is not meant to represent working code.
- The methods for delete will return boolean and not a potentially modified $row
Code generation
Code for executing the plug in events will be added to all models and a call will be executed in all circumstances. This allows users to manually create plugins and not use the Component Creator interface if they prefer.
A general plugin file will be created, but will not hold any custom code. It will essentially work like a controller for the actual code execution that will reside in individual files. One file per table. This is to prevent generating a huge plugin file that could potentially break the whole system if one line is wrong.
Instead we propose a structure like this
/plugins/extension/{componentname}/{componentname}.php
/plugins/extension/{componentname}/Table{tablename}.php
The {componentname}.php will be loaded automatically and will look for files matching the executing methods. If it does not find a matching file, nothing will be executed for that event. If it does find a file, it will be included, and the event method will be executed if available.
The code executed can be entered and maintained on the Component Creator interface.
The individual files will only be created if the user has enabled one or more event triggers for the table (see below).
Interface in Component Creator
Our plan is to allow our users to enable the triggers as needed and store the code they wish executed in the Component Creator interface. This allows for future changes to the code to be rolled out when rebuilding the component, and limits the risk of code being overwritten in the project when re-installing the component.
A new list item will be created on the table list interface with the header “Triggers” each item will show a number indicating how many triggers are active for that table. Clicking on the number will take the user to a new view where triggers can be enabled and code added. The number will change to reflect the number of activated triggers on the table.
A new IDE style editor will be added to facilitate writing sound PHP code, and a few code samples will be provided for easy inclusion and modification (such as a correct database execution).
Installation
The plugin (and table files) will be installed (and if possible activated) when installing the Component Creator extension.
Compatibility
The plug-in architecture has been changed a lot in Joomla 4. For this reason, we propose to only support this functionality in out Joomla 4 builder to not have to implement two separate solutions for this. https://docs.joomla.org/J4.x:Creating_a_Plugin_for_Joomla/en
If there is a huge demand from our users to also support this functionality for Joomla 3, we will consider it.
