|
Monday, May 18, 2026 (#138)
|
|
Some more notes (continuing from this) on WUIDL-tag-to-action-request conversion (currently this only happens in the Futilities):
- The WUIDL Kiosk goes through the user-input (
$this->QInDadex()). For each tuplet found:
- It searches all the Cues (
$this->MainTag()->GetFTags()->InputCues()) to find one that matches.
- This is done by ...
InputCues()->QryIt($sArgKey) (where $sArgKey is the command-code which starts the tuple).
- The matching tag, if found, goes into
$oTDCue.
- From that tag, we then get the enclosing tag-type via
$oTDCue->GetOuter(). (Currently, this is always a request <item>, class Sys\Data\tree\XML\tags\item\Found\ReqItem.)
- The Kiosk then uses
$this->ItemInReqClass($oTDItem) to look up the appropriate Sys\Events\InputRq class to use.
- More specifically (since this is currently a Futilities operation) it's going to be a
Sys\InReq podling, or (in the case of FTM specifically) a Apps\ftm\InReq podling.
- The Kiosk then calls
(InReq class)::FromItemPiece($oTDItem,$oPair) to create the InReq object.
$oPair contains the data-tuplet found earlier.$oTDItem contains the matching found-tag from the UI XML definition.
- Note that although this is a found-tag object,
FromItemPiece() only expects a Sys\Events\InputItem. We could probably assume, in this context, that it's a found-tag -- but if we really want to make use of that, there should probably be a FromItemTag() fake-constructor instead.
- Even if we did that, however, it would not solve the problem of finding the found-tag for an item that isn't in the user-request. We need a way of finding the tag from the master-list of possible tags.
- a clue:
WUIDL::RenderHelpText() displays the list of all command-tags (req-items) supported in the current app.
- Now, how do we get to that from where we are (calling
FindItQ() FetchItQ()- Right now, the errors are coming from
Sys\Events\InputRq\aux\InArgs::FetchItQ(), which is trying to find the defaults in $this->QADefaults() which, as far as I can tell, is never set; possibly it should go away.
$this->FetchItQ() is being called from Apps\ftm\Opts->NBuffSize::get().
- So: tentatively, I could modify how the
ReqItem was being created such that it retains a pointer to the Kiosk, which in this case is WUIDL, which has the list we need -- but then how can Opts access it?
- Isn't the Kiosk a sort of App-global, though?