2026/05/10
Jump to navigation
Jump to search
|
Sunday, May 10, 2026 (#130)
|
|
FTM update
- 12:03 I wonder if part of the problem is... I wonder if the way it works is that the WUIDL tags are only processed when there's a matching item in the command, so defaults never get loaded unless they're overridden? (TLDR: I'm still baffledly trying find the bridge[1] between the two ends of the process (1: where the WUIDL XML is interpreted, and 2: the command-line data).)
- ...or maybe the problem is that the command-data doesn't retain any link back to the tag-type data? (...which would be ok if all tag-default-values were automatically added to the command-data, because so far that's the only thing we need...)
- 15:34 I'm going to brazenly rewrite a bit of the Kiosk system where I tried to use
enums for looking up the class, but it really just made things more complicated and I have standard ways of doing this now.Kiosk/WUIDLdoes$scAct = $this->ItemInReqClass($oTDItem)- which pulls an item-name slug
$sItNamefrom$oTDItem->SName()and passes it to$scAct = $this->InReqClassFor($sItName)and returns$scAct.InReqClassFor()is generally implemented by the current application's Kiosk (e.g.Apps\dba\Kiosk,Apps\ftm\Kiosk).- All extant examples of this then turn around and call a method of their friendly neighborhood
enumto look up the class from the item-name slug -- but this is totally redundant.- TODO It would be better done with an array or a switch statement inside the main clade.
- TODO
FromItemPiece()(called below) could do the lookup directly from the top-level abstract action-class.
- All extant examples of this then turn around and call a method of their friendly neighborhood
- which pulls an item-name slug
- and then does
$oAct = ($scAct)::FromItemPiece($oTDItem,$oPair);, where$scActis the name of aSys/Events/InputRqpodling-class which then instantiates itself.
- 15:45 It should be noted, also, that this seems to be the answer to the question of "where's that confounded bridge?"[1]:
$oTDItemis a, and the end result is anSys\Data\tree\XML\tags\item\FoundInputRq(...although I do need to nail down where the, akaInRqDataInArgsOpts, is created).- 22:09 This is incorrect (where did I get that from?) -- it's a
Sys\Events\InputItem(TODO: document)
- 22:09 This is incorrect (where did I get that from?) -- it's a
- 19:34 It turns out that InArgs (DBA) and Opts (FTM) are actually quite different species; I'm now trying to figure out how they relate to each other, and/or why each app has one but not the other.
Footnote
- ↑ 1.0 1.1 «I'm just trying to find the bridge. Where's that confounded bridge?» -- Led Zeppelin