2026/05/10

From WoozleCodes
< 2026 | 05
Jump to navigation Jump to search
Sunday, May 10, 2026 (#130)
Saturday Sunday Monday posts:prev <this> next

References

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/WUIDL does $scAct = $this->ItemInReqClass($oTDItem)
      • which pulls an item-name slug $sItName from $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 enum to 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.
    • and then does $oAct = ($scAct)::FromItemPiece($oTDItem,$oPair);, where $scAct is the name of a Sys/Events/InputRq podling-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]: $oTDItem is a Sys\Data\tree\XML\tags\item\Found, and the end result is an InputRq (...although I do need to nail down where the InRqData InArgs, aka Opts, is created).
    • 22:09 This is incorrect (where did I get that from?) -- it's a Sys\Events\InputItem (TODO: document)
  • 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. 1.0 1.1 «I'm just trying to find the bridge. Where's that confounded bridge?» -- Led Zeppelin