Futilities/human/lib/caAppBase

From Woozle Writes Code
< Futilities‎ | human‎ | lib
Revision as of 15:57, 27 September 2022 by Woozle (talk | contribs) (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...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
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.

App 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
  • 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->DoSearch($oOpts->Matcher());).