2022/06/24/event-object as output container

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)

originally rubberducked on Discord

08:50

Crikey. Just realized a huge problem with my "stuff everything into Event-object property string" revision scheme: that leaves parent-nodes unable to detect what has been added by child-nodes (as opposed to existing content).

Arrgh.

Ok, well... since the old system required the caller/parent to explicitly incorporate the child's output into its own output, I should implement something similar in the Render Event...

08:52

ugh ugh ugh

09:15

So, before, I was pretty much taking advantage of the call-stack (local variables) to keep things straight. Stuffing all the values into an object means I can't do that anymore. If that's the mechanism I need, then I need to replicate it inside the object -- which seems like wasted/duplicate effort. Maybe I should just... allow OnRender functions to return a string? But then where do they get stuffed back into the Event object? Or is that even necessary? (edited)

09:18

Ok, I think the place it becomes necessary is where the event-chain transitions from general dispatch to calling the Event-class's designated method. That's why I had to eliminate the return value in the first place, because neither of the other two Event-classes needed return values (and future Event-classes might store something other than a string, so it didn't make sense to say "well, okay, they'll just all return strings even if they don't need to").

09:19

This pops up a related concern: when we go to the OnRender() chain, that is explicitly fetching values from sub-nodes and computing results from them -- but OnEvent() could still be passing the Render event down to those subnodes. By what system can I be sure to prevent duplicate rendering?

09:20

I think the original idea was that with OnRender(), I'd discontinue that explicit call-and-calculate methodology... but it seems to be necessary...

09:22

There has to be some way of flagging the fact that the Event has been dispatched, and so OnEvent() should not pass it down further. That would fix one fork of this issue.

09:27

Idea: it would/could actually be an improvement if I were to let the existence of a handler-method in a given class determine whether or not the event-object continues getting passed down the tree.

Caveat: I hope checking an object for the existence of a method isn't an expensive operation. I guess if it later turns out to be, we could also have a flag-member or something... but I bet it's less expensive than an actual method-call, and no more expensive than looking up a member-value.

11:31

There seem to be a lot of places where I've set up RenderBefore/RenderMain/RenderAfter dispatch sequences under various names, and most of them didn't even get used.

20:15

what I eventually worked out

Sometimes I think I spend way too much time refining my nomenclature.

Sometimes I think, well, maybe it wouldn't be necessary for other people, but I need those cues to help me keep things straight.

...and sometimes I think yes, actually nomenclature is important. It needs to be consistent, locally and (as much as possible) globally. Nuance is important. Brain-cell-requirements-reduction is important.

20:33

That said, I think I have this worked out. holds up 8½"x11" sheet of scrap paper with class notes and function names all over it