Futilities/human/lib/caAppBase: Difference between revisions

From Woozle Writes Code
< Futilities‎ | human‎ | lib
Jump to navigation Jump to search
(Created page with "{{fmt/title|Human Futilities: <code>caAppBase</code> class}} ==About== This class-family is intended as a kind of handy framework for managing the overall flow of each Futilit...")
 
 
(2 intermediate revisions by the same user not shown)
Line 2: Line 2:
==About==
==About==
This class-family is intended as a kind of handy framework for managing the overall flow of each Futility. It's configured using static methods, and then begins executing as soon as it is instantiated. The object created does not need to be retained by the main process; everything happens inside of it.
This class-family is intended as a kind of handy framework for managing the overall flow of each Futility. It's configured using static methods, and then begins executing as soon as it is instantiated. The object created does not need to be retained by the main process; everything happens inside of it.
===App class===
==Class==
Since this base class is abstract, each Futility app must cement it with a podling class. Standard practice is to name the concrete podling class <code>cApp</code>.
Since this base class is abstract, each Futility app must cement it with a podling class. Standard practice is to name the concrete podling class <code>cApp</code>.


Creating the App object does the following (in the constructor):
Creating the App object does the following (in the constructor):
* displays standard information identifying the app (it will let the coder know if the necessary details have not been set
* displays standard information identifying the app (it will let the coder know if the necessary details have not been set
** app name and version string
** summary of command format
* opens csTTY for output
* opens csTTY for output
* creates the Options object
* creates the Options object
Line 13: Line 15:
Typical cementing of <code>Go()</code> starts by examining the Options object (via the <code>Options()</code> function, and doing any needed setup as determined by user input arguments.
Typical cementing of <code>Go()</code> starts by examining the Options object (via the <code>Options()</code> function, and doing any needed setup as determined by user input arguments.


Actual processing is then sent through either the Options ({{l/same|caOptsBase}} podling) object (e.g. <syntaxhighlight lang=php inline>$this->Options()->DoCompare()</syntaxhighlight>) or, for operations involving spidering, a {{l/same|cFolderator}} object (e.g. <syntaxhighlight lang=php inline>$of = new cFolderator; $of->DoSearch($oOpts->Matcher());</syntaxhighlight>).
Actual processing is then sent through either the Options ({{l/same|caOptsBase}} podling) object (e.g. <syntaxhighlight lang=php inline>$this->Options()->DoCompare()</syntaxhighlight>) or, for operations involving spidering, a {{l/same|cFolderator}} object (e.g. <syntaxhighlight lang=php inline>$of = new cFolderator; $of->StartSpider($oOpts->Matcher());</syntaxhighlight>).
==Methods==
* {{l/sub|DescribeSelf}}() : string
** Ensures that the App object has been set up properly; emits helpful messages if not.
** Returns version string, formatted nicely.
** '''Note''': {{l/same|caMatch}} and {{l/same|caOptsBase}} each also have a method by this name.

Latest revision as of 19:34, 19 October 2022

Human Futilities: caAppBase class

About

This class-family is intended as a kind of handy framework for managing the overall flow of each Futility. It's configured using static methods, and then begins executing as soon as it is instantiated. The object created does not need to be retained by the main process; everything happens inside of it.

Class

Since this base class is abstract, each Futility app must cement it with a podling class. Standard practice is to name the concrete podling class cApp.

Creating the App object does the following (in the constructor):

  • displays standard information identifying the app (it will let the coder know if the necessary details have not been set
    • app name and version string
    • summary of command format
  • opens csTTY for output
  • creates the Options object
  • invokes the Go() function, which must be cemented by each application.

Typical cementing of Go() starts by examining the Options object (via the Options() function, and doing any needed setup as determined by user input arguments.

Actual processing is then sent through either the Options (caOptsBase podling) object (e.g. $this->Options()->DoCompare()) or, for operations involving spidering, a cFolderator object (e.g. $of = new cFolderator; $of->StartSpider($oOpts->Matcher());).

Methods

  • DescribeSelf() : string
    • Ensures that the App object has been set up properly; emits helpful messages if not.
    • Returns version string, formatted nicely.
    • Note: caMatch and caOptsBase each also have a method by this name.