2022/07/21/render-dispatch rubberduckery

From Woozle Writes Code
Jump to navigation Jump to search
Codeblog

[presses save-all key-combo] I have now probably broken everything that was working before, but it was necessary for the common good. Please ignore the screams.


okay, so OnFigure() is trying to render its chickens before they've been OnFigure()d. Got it.

...why is this happening.

Maybe I need another event-type? Or is that just pushing the problem down another layer?

Ideally, OnFigure() would tell its twigs to OnFigure() before it tried to pull up their renderings. The question is, what's the best way to ensure that this happens? (Follow-up question: why is it happening in the opposite order at present?)

Follow-up answer: the main dispatch goes like this --

OnEvent() calls OnEventLocal() calls DoLocalMethod() which calls the event object's specified method, i.e. in this case DoFIgure()...

...before it calls DoEventTwigs(), which passes the event down to the twigs.

There's probably a reason I did it in that order? Maybe? I guess I'll try reversing it and see what/{if anything} breaks. Having a use-case for needing both ways of doing it, I can then design a solution...

Yeah, getting something not set, presumably done higher up in the tree.

HRMM.

It's like I need something that keeps triggering OnFigure() locally and then in twigs, in a loop. until everyone is happy. That doesn't seem like a good design, but maybe it is? ...or maybe it's the best design I can come up with in the absence of structure-mapping tools?

The other option is some way of bifurcating OnFigure() as needed -- though I'm not sure how I'd even figure out what needs figuring in each furcation...

Maybe if the Event object has a way for called object-methods to tell the dispatch-trunk "I need you to call this additional method (just once) after eventifying the twigs"?

Tentatively, that seems workable.


Much as after throwing a Molotov cocktail, I now have a completely different problem.

At least I hope it's completely different. Worst case is it's just another manifestation of the same problem. It doesn't look like that, though...

Fatal error: Uncaught Error: Call to undefined method ferret\strings\cTemplate_array::parent_SetCells() in /home/htnet/site/git/ferreteria/util/array/status.php:273
Stack trace:

  1. 0 /home/htnet/site/git/ferreteria/base/exception.php(357): ferret\strings\cTemplate_array->SetCells()
  2. 1 /home/htnet/site/git/ferreteria/base/exception.php(48): ferret\except\cNative->GetMessageText()
  3. 2 /home/htnet/site/git/ferreteria/base/app.php(66): ferret\except\cBase->MessageToShow()
  4. 3 /home/htnet/site/git/greenmine/config/portable/www/index.php(22): ferret\caAppBasic->Go()
  5. 4 {main}

  thrown in /home/htnet/site/git/ferreteria/util/array/status.php on line 273

Shutdown

Error #1 in /home/htnet/site/git/ferreteria/util/array/status.php line 273:

 - Uncaught Error: Call to undefined method ferret\strings\cTemplate_array::parent_SetCells() in /home/htnet/site/git/ferreteria/util/array/status.php:273
Stack trace:
#0 /home/htnet/site/git/ferreteria/base/exception.php(357): ferret\strings\cTemplate_array->SetCells()
#1 /home/htnet/site/git/ferreteria/base/exception.php(48): ferret\except\cNative->GetMessageText()
#2 /home/htnet/site/git/ferreteria/base/app.php(66): ferret\except\cBase->MessageToShow()
#3 /home/htnet/site/git/greenmine/config/portable/www/index.php(22): ferret\caAppBasic->Go()
#4 {main}
thrown

(Note: this is much more readable than as rendered by the browser, which ignores line-breaks in accordance with HTML rules.)