2021/11/05/notes for event-system burndown

Codeblog 2024/11/14 untangling setup calls - mostly just notes to myself 2023/06/04 config classes 2023/05/01 DataPorts redesign 2022/07/21 FutilityCloud process design 2022/08/14 Windows joke I wrote in the late 1900s (on TootCat) 2022/07/21 render-dispatch rubberduckery 2022/07/20 comments on The Home Computer Generation 2022/07/18 layout-event rubberducking 2022/06/24 event-object as output container: the consequences 2022/06/23 event-object as output container: the revision 2022/05/30 more data-class rubberducking 2022/05/20 rubberducking about data classes 2022/01/15 standard CV data format 2021/12/17 The Great Data-Class Restacking 2021/11/25 PHP documentation gripe 2021/11/24 things you can't do in PHP 2021/11/23 PortBank refactoring part 2 2021/11/22 PortBank refactoring part 1 2021/11/08 data objects refactoring 2021/11/05 notes for event-system burndown 2021/07/31 a code mystery 2021/05/31 new PHP wishlist item: first keyword 2021/05/28 a kluge using abstract methods 2021/03/21 PHP wishlist 2020/12/04 (notes) 2020/10/30 (notes) 2020/10/29 (notes) 2020/10/28 (notes) 2020/10/27 (notes: Dovecot on cloud5) 2020/08/29 MediaWiki SpecialPages 2020/08/25 The Plex API 2020/06/12 Ferreteria: thoughts on the Wikcess/flex-data system 2020/04/23 Ferreteria: quick notes on a design issue 2020/04/22 Ferreteria: some thoughts on apps vs. frameworks 2020/02/10 job application (yes, I actually sent this in)

The current system for internal events (intEv) (as opposed to loggable events (logEv), which is entirely separate) seems suboptimal. It doesn't allow passing data, and it may be making call-tracing more difficult.

The intEv system is for when you have a tree of objects which all need to be alerted when the system enters various stages of processing, so they can work in synchrony and without stepping on each other's toes. For example, at one stage, we may need to set a bunch of values without taking any further action, and then a subsequent stage will take action based on those values -- where we can't enforce any specific order in which the objects take action. The event system ensures that every object in the tree is at the same stage of readiness.

Possible changes:

1. (APPROVED) Create a descendable cIntEvent object to contain the event code and whatever data might be needed; pass that to all event methods.

• This would also allow encapsulation of event codes (as class constants).

2. (REJECTED) I wanted to eliminate event codes in favor of named methods, for easier searchability, but I think that runs into problems where objects between the event-emitter and an event-consumer should only need to know about the types of events they consume, rather than every possible event that passes through them.

• The more I think about it, the more this wouldn't even make searchability easier. Some classes/traits already split off event-codes into separate OnEvent[name]() methods.

Revisions

Pieces that need to be updated/rewritten include:

• ftExecutableTwig
  • public function DoEvent(int $nEvent) : void
  • protected function OnEventDispatch(int $nEvent) : void
  • abstract protected function OnCreateElements() : void
  • abstract protected function OnRunCalculations() : void
• ftExecutableTree
  • public function DoEvent(int $nEvent) : void
  • protected function OnEventBefore(int $nEvent) : void
  • protected function OnEventAfter(int $nEvent) : void
• cDropinLink
  • protected function PageEvent(int $nEvent)

Decided not to pass caEvent to these methods, because they didn't need any additional info before:

• OnCreateElements()
• OnRunCalculations()

If it turns out they could work better with event data, this can be changed.