Work towards using concrete events everywhere maintaining b/c

[nikosdion]

Proof of concept / rough draft of the incidental points discussed with @HLeithner on #36042

I will also tag @wilsonge because he's interested in improving MVC and events handling could be very important towards that goal. If you guys think of anyone else who should review it, tag 'em.

Summary of Changes

I made a few additions in the CMS Events package.

Results in events

ResultAwareInterface and its implementing Traits aim to provide a simpler way for Events and event handlers to return values through the events dispatcher.

Right now we only have legacy listeners returning results. The CMSPlugin::registerLegacyListener implements this internally by appending the result of the legacy plugin event handler (plugin method) to a named array event attribute called result.

Moving legacy listeners to event handlers this becomes clunky as I need to do things like this:

$result = $event->getArgument('result') ?? [];
$event->setArgument('result', array_merge($result, [$thisHandlerResult]);

It's very easy to screw up and overwrite the result.

Using the new interface and the traits you can simply do:

$event->addResult($thisHandlerResult);

It's neater, far easier to read (especially for array results) and doesn't let the developer mess up the results array. There's a provision to make setArgument('result', ....) no longer work FOR NEW EVENTS ONLY (event names introduced in 4.1 or later versions) and ONLY if these are NEVER going to be used through a legacy handler, since the CMSPlugin will always try to use setArgument for the results of legacy listeners. In 5.0 the only option will be disabling setArgument for the result named argument since we won't need to support legacy handlers in CMSPlugin anymore.

There is also a provision to make it work with immutable events too, appending results being the only mutable part of the event. Purists will cringe BUT being practical is more important. In most cases we want the arguments we pass to the event to be fully immutable and yet we need to receive a result. That's what I was telling @HermanPeeren and @nibra (back in 2016 in the very first J4WG) was my only trepidation on the proposed orthogonality of events handling. We definitely have tons of use cases where returning a result is necessary.

Results are type–checked before being appended to the named argument 'result'. I have included a number of traits which implement the type checks to avoid boilerplate code extravaganza. The traits also support nullable types and Joomla's stupid legacy scalar-or-boolean-false union type (e.g. array|false). By default BOTH nullable AND false-able are disabled and have to be explicitly enabled in the constructor of the event if an event uses them. I strongly recommend against false-able types. They are an icky leftover from the Mambo days, before nullable types were a thing and before Joomla started using Exceptions for communicating errors (still an ongoing process as Harald can attest).

Auto-mapping core event names to concrete event classes

See the CoreEventAware trait. You give it an event name and it tells you which concrete event class you should use. I am using this in the application's EventAwareTrait to migrate triggerEvent from generic events to concrete events where possible. This will allow us to rewrite core plugins to use concrete classes EVEN THOUGH third party developers may still be using the application's tiggerEvent() method to call them. This will be extraordinarily important when we create a concrete class for onContentPrepare 😉

Reshaping argument for b/c

It's best to read the comment block in ReshapeArgumentsAware trait.

The short version is that concrete events use named arguments whereas legacy event listeners use positional arguments. For the two to mix well in the transition period of Joomla 4.x, before we move to concrete event classes and named arguments only, we need to ensure that all named arguments are also given in the correct number and order to work as positional arguments by CMSPlugin::registerLegacyListener.

That trait handles that, it just needs to be called from the constructor of the concrete event. You give it the array of named arguments passed, the expected argument names and optionally an array with the default values for optional parameters (think about the optional arguments in legacy plugin listener methods).

!!! THIS IS A DRAFT PULL REQUEST !!!

I am just submitting a code dump that came out of my head. I have not tested it at all. It definitely needs unit test, it probably needs some finessing.

The purpose of this draft PR is to show you what I had in mind about Events back in 2016 plus everything I have hitherto learned and thought of. Somewhere between getting married, moving houses (thrice), having a child, the need to rewrite my software for Joomla 4 and PHP 8, and a global pandemic I never managed to get there. Well, maybe it's a good thing because in those 6 ½ years I got experience (and PHP moved on in leaps and bounds), allowing me to write much more economical code than I had originally envisioned.

I want your feedback on the direction I am taking this. Does this look good or I am pulling this to the wrong direction? Questions? Ideas? Profound tidbits of knowledge? Everything's welcome and nothing's set in stone.

[HLeithner]

I took only a quick look and will come back to this next week, because I'm busy this weekend.

But some trivial questions.

1. eventNameToConcreteClass needs to old all legacy events incl. the mapping to the new event?
2. the code in getEventClassByEventName for onWebAssetRegistryChangedAsset is just example code if some special is needed that couldn't solved by the array right?
3. ReshapeArgumentsAware will be removed in j5 right?
4. ResultAware (and interface) lives longer? So would you expect we keep "result" as default? variable name? I tought we would have more meaningful names for each event. ex. GetIconEvent would set "icon" and not "result" or I'm wrong?
5. looking at ResultTypeArrayAware, would mean we keep the "broken" results for refactored events? or can be proved correct types for alternative values getArgument('eventSpecificNotFalse') and at the same time have getArguemnt('result') is false instead of null?
6. Also the now introduced traits (ReshapeArguments) should be marked as internal so 3rd party developer shouldn't use them to convert there events.

Like sad just a quick look because busy...

[nikosdion]

1. Correct. It needs to have all the event names with concrete event classes. Once we are done migrating all events it will indeed contain all of the core event names.
2. Correct. So far it was the only event name which could not be resolved with the array. This could also be the case if we have for example controllers create onComSomethingControllernameBeforeTaskname events (random example, not necessarily something we would be doing).
3. Correct. This is a b/c shim needed only for the transitional period (Joomla 4) where we still have CMSPlugin create legacy event listeners.
4. Correct. We should always use a named attribute called result for output purposes. This is essentially a reserved name. Any developer working with any unfamiliar event would know that EITHER the event implements ResultAwareInterface and uses addResult() to add to the result named argument OR it does not support return values. Having it uniform across events minimises the chance of screw-ups of colossal proportions. Ask me how I know :)
5. I assume by broken you mean the "false-able" non-Boolean types? These are currently opt-in and that would be a feature I'd like remove in Joomla 5. Results should be a. scalars; b. union types consisting only of class names; or c. nullables. Union types with non-Boolean values and Boolean false are icky and need to be removed by Joomla 5. They were used instead of Exceptions which we both agree is not good at all. So, this part of the ResultAware traits would indeed be removed in Joomla 5, that's why it's marked deprecated.
6. I disagree. We should mark them deprecated. During the transitional period 3PDs will also need to use these traits. Remember that 3PDs like me define their own events. When I move my code into concrete event classes I will need to use ReshapeArgumentsAware to allow other people's code handling my software's events to continue working.

Well, you said you took a quick look but you really caught every single major thing that went through my mind as I was writing this code :)

[nikosdion]

@HLeithner It's been nearly two months. Can you please provide some feedback so I know if this draft should be converted to a real PR? You may want to consult with @nibra @bembelimen and @roland-d since this touches all Joomla versions from 4.1 onwards.

[HLeithner]

Sorry it did take so long...

I added some comments (mostly sugar/options).

One other thing reading the comment. The Joomla event system would move into "simple return values" for all events? so setArgument method is/should not longer used?

The rest looks pretty fine, for me. maybe we also get some feedback from @nibra on this. but I think it should be the way to go and if possible be included in 4.2, I think it's not worse the hassle to integrate it into patch releases even if it's full b/c.

[nikosdion]

@HLeithner Regarding setArgument: you are thinking that all events are immutable which is not the case for two reasons.

Some Joomla events will have to remain mutable. Think about onContentPrepare, for example. It's meant to be a chain. Each event handler modifies the text which is passed as an input argument. The next event handler works on the modified text and so on and so forth.

Third party developers have legitimate uses cases where they want mutable events. If the argument to be directly modified is not an object we need a mutable event and setArgument.

Finally, keep in mind that immutable events already forbid the use of setArgument.

Therefore it's up to us to slowly migrate all core Joomla events with immutable arguments to be immutable events. That's the correct architectural solution and what we had agreed back in August 2015 in Denmark. @nibra and @HermanPeeren had argued that all events should be immutable but I am saying that this isn't possible without a hard b/c break. For example, onContentPrepare would have to always accept an object instead of plain text but that would break b/c as far as I can see. Maybe we COULD throw a deprecated warning in the log throughout Joomla 4.x when this happens and move these events to only accept objects as arguments and have them extend the immutable event, thereby effectively disabling setArgument without screwing 3PDs who are in need of a mutable event.

PS: I am currently undercaffeinated and sleep deprived. If I said something stupid feel free to correct me.

[HLeithner]

It's not that I expect that all events are/should be immutable, I just wondering if all core events should follow this pattern. Especially as there is a concept about splitting events and hooks which I would expect to be over engineering this part a bit.

Of course we should be as b/c as possible, also if we can't move all events to immutable. I would expect the onContentPrepare event is the most used in Joomla, kill/reworking this without a b/c layer for longer then 4 (J 5-6 or forever) seems not really user and 3rd party friendly. ymmv.

I think the rest looks good and we should aim to get this into 4.2 so 3rd party devs have enough time for j5 to move forward.

btw. there is an initiative to create Joomla developer "only" documentation written in markdown using a github repo where we can/should/would document the event system and the migration for developer. So if you write some documentation here in markdown we/you could easily move it to the new repo as soon as they are ready to accept PRs.

[roland-d]

@nikosdion I have looked through the code, read all the comments and I am happy to see work is being done on the the event system. I have not added any feedback on the code as it is still draft. I like where this is going but haven't tested anything yet.

If we can get this into a production state I would be glad to include it in 4.2.

[nikosdion]

@roland-d I have rebased this upon 4.2-dev and removed the draft status. Feel free to do a regular code review.

If the concept works for you and it gets merged I can start working on the next logical steps: addressing the places where Joomla core events are defined by name and adding concrete classes to each core event not already having a concrete class.

Let me explain the first point, as it'd logically be the next PR.

BaseDatabaseModel, ListModel, and AdminModel let the developer define the names of the events which will be called under some circumstances, e.g. AdminModel lets you set the event_after_delete property to the name of the event to be used after deleting a record, by default onContentAfterDelete.

When onContentAfterDelete has a concrete Event subclass we will need to somehow use it. At the very least, the CoreEventAware trait does that for us. However, in Joomla 5 we won't have that trait since the EventAware trait which uses it will go away. Therefore in Joomla 4 we need to allow the developer to set that property to either an event name or an event class name. The logic would be simple:

• Does a class with a name matching this property's value exist? If so, use it.
• Does the CoreEventAware trait report that a concrete Event subclass exists for the event name equal to this property's value? Use that and log a deprecated notice.
• Otherwise we assume it's a custom event name. We instantiate a GenericEvent object, assign it that event name, set its attributes and merrily go about our way firing that event.
  This will allow developers to write extensions which work on both Joomla 4 and Joomla 5, without fugly if-blocks, without headaches. For 99% of extensions which simply use the default event names as defined by the core *Model class' constructor the developers will be blissfully unaware of the underlying change. Come Joomla 5 all we will need to do is remove the compatibility layer which will be conveniently placed into a Trait. I like keeping things simple and maintainable.

[HLeithner]

@nikosdion can you add at least one event so it can be tested?

[HLeithner]

@nikosdion can you add at least one event so it can be tested?

[nikosdion]

@HLeithner I have already added support for the concrete event classes already added in Joomla 4. I think the GetIconEvent and DisplayEvent are easy targets for testing, no?

[HLeithner]

sorry my fault, I overlooked the GetIconEvent and didn't checked all events. Thanks that's enough of course.

[HLeithner]

Sorry that you have to wait but I don't know when I have time this weekend to answer.

But before we change this signature, I would like talk to other maintainers to get an ok from them too.

[nikosdion]

OK, no problem. Just a heads up, the next couple of week I am unlikely to have any time — but at least I've done enough in my branch to be able to pick it up whenever / if you agree with this direction.

In the meantime I will have released the new version of LoginGuard with a backport of these ideas under my own namespace so I'll at least gain experience about the real world use of this code.

[laoneo]

I didn't dig too deep into the code and did also not test it yet. Just to have a real world example from the plugin developer perspective who consumes the event. Will the following examples both work beside each other?

Old way:

public function onContentBeforeDisplay($context, &$row, &$params, $page = 0)
{
    return 'demo';
}

New way (Arguments are just an example, don't take the arguments for granted):

public static function getSubscribedEvents(): array
{
    return [ 'onContentBeforeDisplay' => 'onDisplay' ];
}

public function onDisplay(DisplayEvent $e)
{
    $e->setArgument('content', 'demo');
}

[nikosdion]

@laoneo The latter onDisplay event handler is wrong because there's no content argument in the event. Right now (Joomla 4.1.0) you would need to do this:

$result = $e->getArgument('result');
$result[] = 'demo';
$e->setArgument('result', $result);

This would work just fine with the PR, but it's a kludge :) So I added the addResult method which turns it back into an one-liner:

$e->addResult('demo');

Both of these approaches AS WELL AS the legacy one will work just fine side-by-side.

I would never break existing code. Legacy handlers will work just fine until the end of the 4.x release cycle. Since 4.0 let us handle real Events in a clumsy way we have to support that throughout the 4.x release cycle as well. Anything we add has to be built on top of legacy. That's the approach I am taking.

You will also see that in my branch (https://github.com/nikosdion/joomla-cms/tree/feature/event-redux-proposed) I am converting existing concrete events in a way which allows you to create them with BOTH the Joomla 4.0/4.1 way (passing eventname and an array of arguments) AND the new way (passing individual arguments). Since PHP doesn't offer method overloading for constructors (being a loosely typed language and all) I am faking it the same way we've faked it in the past, e.g. when we changed the method signatures for HTMLHelper::_('script').

Again, the objective is to put the foundations for the next, improved iteration of Events handling in core in a way that allows someone to write software which would be simultaneously compatible with Joomla 4 and 5, making upgrades possible, without breaking anything that already works on Joomla 4.

[laoneo]

Then I'm more than happy! I would also add some @trigger_error('...', E_USER_DEPRECATED); statements when legacy is used, otherwise as extension developer there is no indication that a deprecated way is used.

[nikosdion]

@laoneo Fully agree! That's why I did exactly that 5 days ago: https://github.com/nikosdion/joomla-cms/blob/feature/event-redux-proposed/libraries/src/Event/View/DisplayEvent.php#L50-L56

I just want to get the green light from @HLeithner @nibra and the other leadership members so I can keep on converting existing event classes and introduce new ones. I think we've got the backwards and forwards compatibility covered :)

[HLeithner]

I just want to get the green light from @HLeithner @nibra and the other leadership members so I can keep on converting existing event classes and introduce new ones. I think we've got the backwards and forwards compatibility covered :)

Allon is here also because of the discussion in the maintainer chat. So it's ongoing^^

[nikosdion]

Awesome! This week is a great opportunity for the discussion to happen as I don't have time to work on the code anyway 😅

[laoneo]

I will give it tomorrow a test.

[laoneo]

I have tested this item ✅ successfully on 0f9a041

Tested DPCalendar with the pr and can confirm that the old events are working the way I'm using them on Joomla 3.10. Also the icon one which uses the SubscriberInterface works as expected.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/36578.}

[HLeithner]

@nikosdion I had a discussion about events/messages and hooks/callbacks today and the future implementation of the event system in Joomla. Basically the idea is to split messages (Events like "onAfterExecute" where the result is not used) and callbacks (Events with result).

I would simple say adding an interface which describes this behavior is enough for the dispatcher to decide how to interact with the plugin. You more or less added this in https://github.com/joomla/joomla-cms/pull/36578/files#diff-58ec461e3704bfe1e12c23707a90c52718e1d37f2592976bc5256fb0b22f5c4fR56-R59 going a step further and explicit have an interface may would it make more clear.

The other thing is how events handle chained results. At the moment I get $event with the argument $item, since we want this immutable this object would only be clone and should be added with $this->addResult($item) to the result list. The question is now how would one plugin work on the $item of the previous plugin?

One more thing is the question of working more like a middleware and leverage the parameter and result validation to php instead of a ResultTypeXXXAware. I know it's possible todo more then check type, like range validation, the question is it really need? (I know we have "false" allow values and so).

[nikosdion]

Regarding the interface: I had already added the ResultAwareInterface. I am already using it in the GetIconsEvent: class GetIconsEvent extends AbstractImmutableEvent implements ResultAwareInterface. Isn't this what you are saying here?

The other thing is how events handle chained results. At the moment I get $event with the argument $item, since we want this immutable this object would only be clone and should be added with $this->addResult($item) to the result list. The question is now how would one plugin work on the $item of the previous plugin?

This would not be an immutable event :) In fact, this sounds like an event that acts on its input argument, e.g. onContentPrepare. This event would extends from AbstractEvent, NOT AbstractImmutableEvent. However, this has the obvious problem that all arguments can be mutated. We could have an interface PartiallyImmutableEvent and a Trait PartiallyImmutableEventAware where we explicitly set the mutable attributes. For onContentPrepare that would be both $item and $params.

For events which want all their input arguments immutable BUT would like to operate on the previous result, um, this is already possible since Joomla 4.0:

$previousResults = $event->getArgument('result', []);
// I am being stupid here and just assume the only result we wanna keep is the last one
$previousResult = array_pop($previousResults);
// Do something with $previousResult...
$previousResult->foo = 'bar';
// Replace the result
$event->setArgument('result', [$previousResult]);

Just note that this can only work with modern events. Legacy events do not have the notion of chained results. If you get a bit more specific about what event, existing or new, you want to implement I can tell you which approach would be better and why.

One more thing is the question of working more like a middleware and leverage the parameter and result validation to php instead of a ResultTypeXXXAware. I know it's possible todo more then check type, like range validation, the question is it really need? (I know we have "false" allow values and so).

Yes, it's really needed for two reasons:

1. It would require reimplementing addResult on each event class.

2. Overriding the addResult method with a typed parameter changes the method signature in a way that PHP 8.1+ complains about.

Therefore the alternative is to not implement addResult at all and have it implemented in each event separately which is very much not DRY. If someone has a way to implement it without adding a crapload of code in each event class I am open to suggestions. I figured that using a trait (one liner!) is best AND it leaves enough “breadcrumbs” for developers to understand how the magic works.

Also, as you already, said we do get a bonus with this. We can implement our own typeCheckResult method to add range checks, domain logic checks and everything else we need. I believe this will become particularly useful if we migrate towards Union types to replace dictionaries (key-value arrays) in a future version of Joomla. The logical way to do that is introduce another method (typeConvertResult) which would precede the call to typeCheckResult in the addResult method, convert legacy arrays to our Union type and then let a ResultTypeUnionAware trait typecheck and validate our Union type. Once you have this kind of middleware it becomes very easy modernising your code without breaking b/c. If you have PHP type checks you're stuck between a rock and a hard place, especially since PHP is moving to very strict method signature checks before it even considers method overloading (big mistake, in my opinion).

[HLeithner]

hey @nikosdion sorry I didn't comeback here earlier, Niels is not happy with it and I didn't liked to discuss this with him for the moment.

But now I came to this topic back and would like to know why we only do this with 'result', from my point of view it would be really limiting the system. But maybe it's only me.

Why we don't do somthing like

class event {
  function addArgument($name, $value) {
    $this->arguments[$name][] = $value;
  }
  function setArgument($name, $value) {
    $this->addArgument($name, $value); // we never override arguments
  }
  function getArgument($name) {
    return $this->arguments[$name][count($this->arguments[$name])-1];
  }
  function getArguments($name) {
    return $this->arguments[$name];
  }
  function getArgumentOriginal($name) {
    return $this->arguments[$name][0];
  }
}

That's complete pseudo code of course and all the checks have to be added (also the typeCheckResult traits). At least I see no reason to limit it only to the 'result' argument. Of course if we need it different for the result type because of b/c then we keep it only for this different? Or do I completely miss something? thanks.

[nikosdion]

The pseudocode you wrote is a mutable event. We already have that 😉

The problem is, we want our events to be immutable (so the event handlers can't add, remove or change arguments) BUT for many of them we need to receive scalar results.

In an ideal world we'd have an immutable results argument which is a write-only queue. HOWEVER this would be backwards-INCOMPATIBLE. In Joomla 4 the results argument is a scalar array and handlers can reasonable expect to read its values as an array, add to the array or even completely replace the array. So, we cannot do it the ideal way.

This leaves us with the need to replace the scalar array result argument in otherwise immutable events. Hence the code I added.

In the end of the day, it comes down to this. Immutable events. Backwards compatibility. Doing it right. PICK TWO (2).

[HLeithner]

I know my feedback speed could be better... but other things came between me and joomla...
anyway last question then we can go I think.

We don't have a way to easily "chain" plugins right? What I mean is for example the onContentPrepareData event we set the $context and the $data (which could be mixed.... what a pain). in this case a plugin would work would like to work with $data.

(I know it's not a good example because the $data is modified directly by the plugin as reference, which I would expect is wrong per concept because we would like to validated the modification before the next plugin gets the new data right?)

function onContentPrepareData($event) {
  $data = $event->get('data');
  $data['myvalue'] = 'awesome';
  $event->addResult($data);
}

the next plugin would need a logic to get the data or the result ?

function onContentPrepareData($event) {
  $data = count($event->getResult()) > 0; $event->getResult() ? $event->get('data');
  $data['myvalue'] = 'awesome';
  $event->addResult($data);
}

Also in this case getResult is the wrong function name because I would get more then one results so it should be getResults?

The other thing is the context I would like to talk again with you but first finish this. topic.

[nikosdion]

The answer to this question predates any changes I have made and is part of the existing Joomla Framework Event package 😉

When there are chained plugins we do not return a result. We modify the argument itself. This has always been the case in Joomla.

In this case the Event would be mutable, i.e. its arguments can be changed by any plugin in the chain. For onContentPrepareData the code would be:

$data = $event['data'];
$data['myvalue'] = 'awesome';
$event['data'] = $data;

Or you could also do:

$data = &$event['data'];
$data['myvalue'] = 'awesome';

The next plugin can access the data attribute.

(Side note: we could of course implement these events as immutable with JUST one argument being mutable, the same way my code uses immutable events with a mutable result parameter. This would be functionally equivalent to what Joomla does now in legacy event handlers, where only one argument is sent by-reference therefore mutable. We could even abstract that behaviour into a Trait.)

These events work kinda-sorta like middleware.

I say kinda-sorta because a plugin handler implicitly lets the execution flow to the next handler unless it calls $event->stopPropagation() whereas middleware would have to explicitly call the next middleware hander (or not, if it wants to stop the flow). Moreover, a Joomla event handler modifies the input argument instead of returning the modified argument. This is conceptually the opposite to the Middleware pattern but functionally identical — and keeps things beautifully backwards compatible.

[HLeithner]

Ok but in this case (how it is now) we don't validate anything and should get rid of it right? And the events which are immutable provide always the same content to all plugins and the caller have to work on all results. In this case it's not a middleware and more a messaging bus with a result value for each plugin.

Just to get it right. In the end we have 3 types of events.

1. Immutable without result (messages)
2. Immutable with a array of results (where all results could be overridden by each plugin as long as preventSetArgumentResult is false)
3. Mutable where Sodom und Gomorra can do more or less everything as long as no validation is on in the Event class but the only way to do the middleware like interface

[nikosdion]

So, what I said is that you can have some kind of validation in the event itself IF you make it immutable AND use a bespoke setter for its only mutable argument.

However, also keep in mind that a lot of Joomla events, especially in the content family, pass around plain objects, typed objects and arrays like there's no tomorrow. What kind of validation are you doing in the event? It's impossible. That's why I never used generic catch-all-and-then-some events in FOF. It makes far more sense to have onComContentPrepareContent knowing that it expects a stdClass object with specific properties. That can be validated. What you have now, cannot. So, yeah, you're stuck with that in very generic events, they're just a stupid message bus and hope for the best.

Other events, however, pass specific object types. For example, all events handling queries. These CAN be worked into something approximating middleware.

Eventually, it'd make sense to migrate away from events using a context argument. If you need to pass a context it means you should have a different event name and type! Anyway, that's another fight for another day.

Just to get it right. In the end we have 3 types of events.

Immutable without result (messages)
Immutable with a array of results (where all results could be overridden by each plugin as long as preventSetArgumentResult is false)
Mutable where Sodom und Gomorra can do more or less everything as long as no validation is on in the Event class but the only way to do the middleware like interface

Correct.

The second case sounds like a bug but it's actually what Joomla 4 does right now. Eventually we'll move away from GenericEvent for them and implement them as concrete events with preventSetArgumentResult set to true. Then we can fix the Wild West that Joomla 4 introduced by accident 😉

[HLeithner]

Ok thanks, I asked for a last feedback round from maintainers and if the pr is ready and you are ready and no further concerns are raised I would merge in one week.

[nikosdion]

Whoop! Whoop! Whoop! Thank you :)

[laoneo]

Can extension devs also benefit from this pr as I see some hardcoded stuff for core events. Is there a way for 3rd party extension devs to register their names? Or do I miss here something?

[nikosdion]

Yup, you do miss the fact that extension developer can already create their own concrete event classes. I proved that in LoginGuard. See https://github.com/akeeba/loginguard/tree/development/component/backend/src/Event (which includes a backport of some of the code in this PR) and how I use these custom concrete events in plugins e.g. https://github.com/akeeba/loginguard/blob/development/plugins/loginguard/email/src/Extension/Email.php You can see how I call these events e.g. https://github.com/akeeba/loginguard/blob/development/component/backend/src/Controller/CaptiveController.php#L189

These are all possible since Joomla 4.0. The benefit of this PR to 3PDs is that concrete events can have a setResult method which validates data types (instead of being a dumb array) AND the custom event classes are ultra compact, e.g. https://github.com/akeeba/loginguard/blob/development/component/backend/src/Event/GetInfo.php

I actually wrote LoginGuard like that as a proof of concept of the utility of this PR in third party code.

[HLeithner]

I'm merging this without 2 tests because it's mainly a foundation PR which allow us to transform our events to the new systems and we would find errors while testing them.

@nikosdion thanks for this, it would be great if we can find some time (when we have a new programmers docu) to write a good documentation about the complete plugin system!

[nikosdion]

THANK YOU!

I will also amend my TFA PR (#37811) to use concrete event classes and show people how it's done.

I agree, we need better documentation for the plugin system. It's changed too much since Joomla 1.5, all documentation people can find is outdated. When to do that... That's a pained question. Can you find me an extra 6 hours a day? I could really use them 🤣