Futilities/v0.6/clade/Kiosk/@history
< Futilities | v0.6 | clade | Kiosk
Jump to navigation
Jump to search
|
Revision History
|
2024
* for HasAppOption(), use AppOpts()->HasIt($sText) instead
- 2024-09-15 reworking this as a wrapper around the incoming Request
- 2024-09-19 ...and making it a Kiosk podling, which I hope is the right move.
- 2024-09-20
- renamed HasSearchArgs() -> HasCmdTerms()
- (in accordance with earlier note suggesting this)
- because less confusing / more accurately descriptive
- changing ParseCommand() to read from InReq instead of expecting argv[]
- renamed HasSearchArgs() -> HasCmdTerms()
- 2024-09-22 Much rearranging.
- contents of ProcessUserInput() moved into Respond()
- ...except for ParseCommand(), whose obsolete implementation is now taken care of earlier.
- contents of ProcessUserInput() moved into Respond()
- 2024-10-01 [RenderAppOptions()] redundant (commenting out old version)
- Renamed ShowAppOptions() -> RenderAppOptions()
- ...and moved all the functionality into AppOpts() (t.k.a. OptsKnown()), to keep it encapsulated.
- THINKING: It's "App" because...
- AppOptions: options supported by the app
- CmdOPtions: options actually engaged by the user (on the command-line)
- xACTION: renders (in user-friendly format) the list of availble command options
- At some point, this became a coding-prompt to be implemented by podling-classes.
- 2024-10-06:
- These appear to be no longer in use -- now commented out:
- private $arCmdOptsByKey = [];
- private $arCmdOptsBySeq = [];
- protected function AddCmdOption(cOptMain $oo) {
- public function GetCmdOptionsBySeq() : array { return $this->arCmdOptsBySeq; }
- protected function GetCmdOptionsByKey() : array { return $this->arCmdOptsByKey; }
- protected function HasCmdOption(string $sText) : bool {
- protected function GetCmdOptionByKey(string $sText) : cOptMain {
- This was only called by retired code above it:
- public function ListCmdOptions(string $sPfx = ' ') : ?string
- These appear to be no longer in use -- now commented out:
- 2024-10-12 It makes no sense for BuildOptsKnown() to return an OptsTagIface* when the idea of an options-tag is only introduced in WUIDL. TODO
- (*now TermsTagIface)
* 2024-10-13 We want to have an OptsKnown() method at this level, but we don't want it to be dependent on tag-oriented objects. THINKING: "OptsKnown" returns a keyed array interface (ArrayIface), which can be tacked onto the opts tag-class if it hasn't already been.
* Renaming OptsKnown() -> AppOpts() (juxtaposed with CmdOpts(), which would be the option-values specified in the command-line).
* 2024-11-07 see [#2024-11-07] section
* 2024-11-11
* Let's try this terminology:
* AppOptions/AppOpts -> Options
* CmdOptions/CmdOpts -> Actions
* Renaming:
* RenderAppOptions() -> RenderOptions()
* AppOpts() -> Options()
* BuildAppOpts() -> BuildOptions()
## 2023
* 2023-01-19 renamed GetCmdOption() -> GetCmdOptionByKey()
* 2023-09-30 [RenderAppOptions()] xTODO Should probably be renamed RenderAppOptions().
* (...except, why *App*Options?) (Answer: see 2024-10-01)
## 2022
* 2022-07-29 created
* 2022-08-01 [HasAppOption(string $sText) : bool]: added check for value
* PURPOSE: checks to see if the option-index includes the given option
* INPUT:
* $sText = full option parameter, possibly including value (demarcated by ':' or '=')
* 2022-10-20
* [RenderAppOptions()] Improving this a bit so it groups all option aliases together
* xTODO: make it possible for each option to have a brief description as well
* created ListCmdOptions(string $sPfx = ' ') : ?string