2022/07/21/render-dispatch rubberduckery: Difference between revisions
(Created page with "{{nav/codeblog}} category:ferreteria ''[presses save-all key-combo]'' I have now probably broken everything that was working before, but it was necessary for the common go...") |
No edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 3: | Line 3: | ||
''[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. | ''[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 | okay, so <code>OnFigure()</code> is trying to render its chickens before they've been <code>OnFigure()</code>d. Got it. | ||
...why is this happening. | ...why is this happening. | ||
| Line 9: | Line 9: | ||
Maybe I need another event-type? Or is that just pushing the problem down another layer? | 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?) | Ideally, <code>OnFigure()</code> would tell its twigs to <code>OnFigure()</code> ''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 -- | '''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()... | : <code>OnEvent()</code> calls <code>OnEventLocal()</code> calls <code>DoLocalMethod()</code> which calls the event object's specified method, i.e. in this case <code>DoFIgure()</code>... | ||
...''before'' it calls DoEventTwigs(), which passes the event down to the twigs. | ...''before'' it calls <code>DoEventTwigs()</code>, 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... | 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... | ||
| Line 21: | Line 21: | ||
HRMM. | 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? | It's like I need something that keeps triggering <code>OnFigure()</code> 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... | The other option is some way of bifurcating <code>OnFigure()</code> 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"? | 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"? | ||
Latest revision as of 14:34, 22 July 2022
[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()callsOnEventLocal()callsDoLocalMethod()which calls the event object's specified method, i.e. in this caseDoFIgure()...
...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:
- 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 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.)