2026/05/11

Monday, May 11, 2026 (#131)

Sunday Monday Tuesday posts: prev < this > next

References Ferreteria/v0.6/sys/Requests (← links) Futilities/v0.6/clade/Kiosk/WUIDL (← links) Ferreteria/v0.6/clade/Sys/Events/InputItem (← links) Ferreteria/v0.6/clade/Sys/FileSys/Aspect/Ident/spex/FSChain (← links) Futilities/v0.6/clade/Kiosk/@history (← links) Ferreteria/v0.6/clade/Sys/FileSys/Aspect/Ident/spex/FSChain/@removed (← links) 2026/05/10 (← links) Futilities/v0.6/clade/Apps/ftm/Kiosk/@code/removed (← links) Ferreteria/v0.6/clade/Sys/Data/tree/XML/tags/item/Found/ReqItem (← links) 2026/05/12 (← links) 2026/05/18 (← links)

FTM update

yesterday's do-list

#	status	to-do	done
1.	✅ DONE	It would be better done with an array or a switch statement inside the main clade.	enums removed
2.	🛠️ xTODO	FromItemPiece() could do the lookup directly from the top-level abstract action-class.
3.	✅ DONE	document Sys\Events\InputItem

Item #2 looks more complicated than I thought at first...

• The WUIDL Kiosk object is what looks up the tag-class to instantiate:
  • $scAct = $this->ItemInReqClass($oTDItem)
    • ...pulls out the item-tag's name ($sItName = $o->SName()) and calls
      • $scAct = $this->InReqClassFor($sItName) to get the class.
• The InReqClassFor() lookup is instantiated by each application's Kiosk class, which is where the list of XML-names comes in.
• The objects being created are ultimately podlings of Sys\Events\InputRq.
• I could possibly have a FromReqName() quasiconstructor in each application's InputRq-podling, at the same level as its Kiosk.
  • Is it worth the trouble? ...or, how about...
  • Is it even a good idea?
    • The current structure at least gives us the flexibility to keep the InputRq family-structure separate from the navigation-structure of interpreting the request-items.
      • This flexibility is actually used in DBA, where each InputRq-podling is descended directly from a clade in Sys\Data\Engine\aux\ActionRq\Admin.
        • 🛠️ TODO: either lowercase DBA's InReq folder (to indicate nonstandard descent) or switch things around to use traits.
      • ...so I kinda think no, at least for now.
• I am therefore cancelling item #2.

accessing default values

Wherever it is that we look up request-data needs to have access to the list of possible requests (i.e. <input> tag subtypes) so that if it does not find a given value in the request, it can get the default from the tag-type.

(The alternative is to decide that the UI definition should not include defaults, because that's more of a config thing. I find this argument persuasive but not convincing.)

• Q: What creates the InArgs object? That seems like where the available-items info should be stored.
  • At first, it looks like it's created in Kiosk::Actions() (moved from WUIDL), but that's just a simple DStor and yet the problematic lookup ($this->FetchItQ(self::KI_BUFF_SIZE)) is in Opts -- so, what's actually going on here?
    • Kiosk::Actions() is being called (commenting it out results in an error). Maybe the data is being copied over to Opts later on?
      • 🛈 Opts is a QStor, not a DStor...

QStor objects can't be directly constructed; Opts reports these fake-constructors as being available:

FromOArray            | [WFe]/Sys/Data/Things/Array/QStor.php           | 23  |
FromStore             | [WFe]/Sys/Data/Things/Array/ifaces/Whole.php    | 45  |
FromVArray            | [WFe]/Sys/Data/Things/Array/ifaces/Whole.php    | 50  |

Possibly one of them is being used to send the data over?

Continued: 2026/05/18