Futilities/v0.6/clade/Kiosk: Difference between revisions

From Woozle Writes Code
< Futilities‎ | v0.6‎ | clade
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
{{page/clade/v2
{{page/clade/v2
|fam=
|fam=
{{!}} align=right  {{!}} [WFe]{{l/ver/clade|p=ferreteria|Sys\Routing|Kiosk}}[ca]
{{!}} align=right  {{!}} [WFe]{{l/ver/clade|p=ferreteria|Sys\Routing|Kiosk}}
{{!}} align=center {{!}} &rArr; {{l/ver/clade/base|Kiosk}} &rArr;
{{!}} align=center {{!}} &rArr; {{l/ver/clade/base|Kiosk}} &rArr;
{{!}} align=left  {{!}}
{{!}} align=left  {{!}}
Line 14: Line 14:
{{!-!}} '''QStr'''*  [c,i] {{!!}} {{l/ver/clade/full|p=ferreteria|Data\Mem\QVar|Str}}
{{!-!}} '''QStr'''*  [c,i] {{!!}} {{l/ver/clade/full|p=ferreteria|Data\Mem\QVar|Str}}
}}
}}
==About==
* PURPOSE: base class for parsing and managing command-line options
** I originally tried to use <code>[https://www.php.net/manual/en/function.getopt.php getopt()]</code>, but the way it does stuff just adds confusion and removes flexibility.
==Terminology==
==Terminology==
At one point I was using the following:
At one point I was using the following:
* AppOptions - the options made available by the app
* AppOptions - the options made available by the app
Line 23: Line 25:
==Pages==
==Pages==
* [[/@history/]]
* [[/@history/]]
 
* [[/@thinking/]]
<syntaxhighlight lang=markdown>
* [[/@removed/]]
# Details
 
## 2024-12-19
 
```php
    private $oTerms = NULL;
    // RETURNS: an object encapsulating the *available* CLI options
    public function Terms() : TermsIface { return $this->oTerms ?? ($this->oTerms = $this->NewTerms()); }
    // 2024-12-16 old methodology
    public function Terms() : TermsIface { return $this->oTerms ?? ($this->oTerms = $this->BuildTerms()); }
    protected function BuildTerms() : TermsIface { echo self::PromptForMethod(); }
```
 
## 2024-11-07
 
We really need better terminology around Opts and Options. Opts has AppOpts() which returns a different class altogether.
      * I'm going to start the de-tangling efforts by removing the Base2Iface & Base2Trait stuff.
        * It doesn't make sense to have [WF]Sys\Data\Options as a parent *and* as a returned object (AppOpts() returns OptionsIface, which aliases to the same exact class).
      * Next, renaming iOpts/caOpts -> iKiosk/caKiosk, and removing commented-out code that seems unlikely to be applicable anymore. This includes:
        * protected function GetAppOptionKey(string $sText) : string { return $this->arAppOpts[$sText]; }
        * these bits which were already commented out on 2024-10-06:
```php
    /**----
      THINKING: This is a facility that will not always be used. The idea is that sometimes
        we want to treat options as commands which can be repeated with different arguments,
        rather than just as options. Maybe this is actually a bad idea...
    */
    public function DoSerially() {
        $arOpts = $this->GetCmdOptionsBySeq();
        foreach ($arOpts as $nIdx => $oOpt) {
            $sName = $oOpt->GetKey();
            $sKey = $this->GetAppOptionKey($sName);
            $this->DoSerialOption($sKey);
        }
    }
    // STUB
    protected function DoSerialOption(int $nSeq) {}
 
    // ++ COMMAND: TERMS ++ //
 
    // 2024-10-06 More old command-term stuff that doesn't appear to be in use.
 
    private $arTerms = [];
    protected function AddCmdTerm(string $sText) {
        $this->arTerms[] = $sText;
    }
    protected function GetCmdTerms() : array { return $this->arTerms; }
 
    // 2022-08-05 Should probably be renamed to "HasTerms()", OSLT, for generalization
    public function HasCmdTerms() : bool { return count($this->GetCmdTerms()) > 0; }
 
    // ++ COMMAND: DEFINED OPTIONS ++ //
 
    public function ShowProgress()  : bool {
        // if we're listing anything, that fights with the progress-shower
        return ($this->HasCmdOption(self::ksOPT_SHOW_PROGRESS) and !$this->ListingOptions()->UseScreen());
    }
 
// ...
 
    // ++ UI: FEEDBACK ++ //
 
    /*----
      NOTE: This sort of includes DescribeSelf(), but gives the information
        in more technical terms -- largely for debugging purposes
    */
    // 2024-10-06 Does not appear to have been used.
    public function DescribeRequest() : string  {
        $arOpt = $this->GetCmdOptions();
        $arTrm = $this->GetCmdTerms();
 
        $out = "++ INPUT DESCRIPTION ++\n";
        $nOpt = count($arOpt);
        if ($nOpt > 0) {
            $sPlur = (($nOpt == 1) ? '' : 's');
            $out .= "Option$sPlur set:\n";
            foreach ($arOpt as $sKey => $oOpt) {
                $sOpt = $oOpt->ShowSelf();
                $out .= " - [$sKey]: $sOpt\n";
            }
        } else {
            $out .= "No input options set.\n";
        }
 
        $nTrm = count($arTrm);
        if ($nTrm > 0) {
            $sPlur = (($nTrm == 1) ? '' : 's');
            $out .= "Term$sPlur:\n";
            foreach ($arTrm as $nIdx => $sVal) {
                $out .= " - [$sVal]\n";
            }
        } else {
            $out .= "No input terms given.\n";
        }
        $out .= "-- INPUT DESCRIPTION --\n";
        return $out;
    }
 
    // -- UI -- //
 
```
</syntaxhighlight>

Revision as of 01:24, 16 November 2025

Clade Family
[WFe]Kiosk Kiosk

Legacy
WUIDL

Clade Aliases
Alias Clade
Base* [c,i] Sys\Routing\Kiosk
FListIface Sys\Data\tree\XML\tags\base\FoundList
ItWent* [c,i] Sys\Events\ItWent
LogIface Data\File\Log\Log
QStr* [c,i] Data\Mem\QVar\Str
Subpages

About

  • PURPOSE: base class for parsing and managing command-line options
    • I originally tried to use getopt(), but the way it does stuff just adds confusion and removes flexibility.

Terminology

At one point I was using the following:

  • AppOptions - the options made available by the app
  • CmdOptions - the options invoked by the user in a particular session

I seem to be gravitating towards just calling AppOptions "Options" and using... some other term for CmdOptions.

Pages