2022/07/18/layout-event rubberducking

Codeblog 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)

Now I've got... [counts...] six copies of the header coming up.
More is better, right? <.<
"My code is now 300% more performant."

[1:55 PM]

The Untanglenating continues...

The problem seems to be with elements that have sub-elements, apparently getting rendered via 2 different paths...

Got it back down to two copies, but my brain is just utterly frazzled by how to make this maintainably debuggable.

[7:09 PM]

Maybe it is time to rethink how it works...

[7:13 PM]

Throwing idea-spaghetti at the wall: howbout I have, liek, an XML doc for the page as a whole, and elements of that can refer to other XML docs for sub-elements...

[7:14 PM]

Question from the class: Why is that any better?

Answer: uhhh... you obviously didn't read last night's seven chapters of documentation that I assigned. I forgot? Well, you should have done them anyway. Class dismissed... <runs away>

I think the problem may originate with trying to treat [rendering] more like the other two types of events. It was previously a separate dispatch chain.

[7:40 PM]

This may be another case of I Thought I Was Being Clever.

[7:42 PM]

...cuz I've ended up partly implementing that separate dispatch chain anyway, and sorting that out has been the major cause of the last 10-20+ hours I've spent on this.

[7:44 PM]

wuttif...

• each element calculates its render output during OnFigure, and stashes that in a variable which can be accessed by, uh, GetRendered() ocelot
• OnRender() just goes through and sums those up. No other dispatch allowed. (All the dispatching would be during OnFigure().)

That way, we maintain clarity about what's being added to the output and what's just being calculated for something else to use.

Sounds nice in theory...

[7:45 PM]

...but I kinda feel like we'll end up in the same spot, somehow...

[7:48 PM]

Oh, here's one way out of the trap: if a parent-object uses the output of GetRendered(), it can clear that so it won't get used again.

...and actually, let's make it automatic: retrieving the rendered output clears it.

Revisionist documentation...

Okay, I need to figure out what the heck I was trying to do with Kiosk objects...