Documentation
¶
Overview ¶
Package m5cli provides a generic command line argument processing capability for XML-oriented programs. It provides a large set of useful arguments that can be individually (or as a group) enabled or disabled (i.e. hidden).
The package imports github.com/fbaube/(fileutils,stringutils,wasmutils) .
Index ¶
- Variables
- func CLI(args []string) error
- func DoSamples()
- func InitContentityDebugFiles(InfileContentities []*cnty.Contentity, doTotalTextal bool)
- func InitLogging(appName string)
- func RunWeb(portNr int) error
- func WriteContentityFStreeFiles(IndirContentityFSs []cnty.ContentityFS)
- type AllFlargs
- type InputPathItems
- type XmlAppCfg
- type XmlAppEnv
Constants ¶
This section is empty.
Variables ¶
var AllGLinks cnty.GLinks
AllGLinks gathers all [mcfile.GLinks] in the current run's input set. This should actually be re-entrant, like [mcfile.ContentityEngine].
var InputExts = []string{
".dita", ".map", ".ditamap", ".xml",
".md", ".markdown", ".mdown", ".mkdn",
".html", ".htm", ".xhtml",
".png", ".gif", ".jpg", ".svg"}
InputExts is a whitelist that more than covers the file types associated with the LwDITA spec. Of course, check for them case-insensitively.
var LOG_LEVEL_EXEC_STAGES = LU.LevelInfo // 6
var LOG_LEVEL_FILE_INTRO = LU.LevelInfo // 6
var LOG_LEVEL_FILE_READING = LU.LevelOkay // 5
var LOG_LEVEL_REF_LINKING = LU.LevelDebug // 7
var LOG_LEVEL_WEB = LU.LevelDebug // 7
var R *os.Root
Functions ¶
func CLI ¶
CLI parses the arguments passed in (via os.Args) and then processes them; therefore it is very easy to pass in whatever arguments are suitable for testing.
NOTE: os.Args is writable so you can also assign your own set of arguments - this might be useful for testing or for WASM usage.
An error from this func is returned unmodified and unprocessed, and so it is up to the caller to sort out its severity and how to handle it (and perhaps what to return to the shell via os.Exit).
NOTE: Do not use logging in the code until the point where the command line invocation has been sorted out.
Outline of operation (possibly OBS):
- flargs (command line "flag arguments") are defined in a func init(), so that they are available for a no-CLI-arg help message
- Check for no-CLI-arg invocation that gets a help message and exits
- InitLogging
- Samples() can do library demos and other very meta stuff
- NewXmlAppCfg creates XmlAppCfg config from CLI arguments
- NewXmlAppEnv creates XmlAppEnv env'mt from XmlAppCfg
- XmlAppEnv.Exec() to Get Things Done
- (If REST port number is given...) Run web UI
.
func DoSamples ¶
func DoSamples()
DoSamples does demo type stuff and can be skipped; it does use (and demo) mlog's L.L
func InitContentityDebugFiles ¶
func InitContentityDebugFiles(InfileContentities []*cnty.Contentity, doTotalTextal bool)
func InitLogging ¶
func InitLogging(appName string)
InitLogging starts with Targets[] empty, then
- adds a console logger (i.e. Stdout),
- adds a file logger named "[appName].log",
- opens them both,
- outputs a few demo log records
func RunWeb ¶
Notes:
- Does not launch a goroutine.
- Call with env.WebPort .
- Used Gorilla mux, but now use pilot version of new Go ServeMux.
Dedicated servers:
- /events :: SSE
- /ws :: websocket upgrader
- /rest :: REST server (on a different port nr)
- /htmx :: htmx responder (??; https://github.com/angelofallars/htmx-go)
Main server (with h2c):
- /all :: list of all endpoints
- / :: something bland
- /app :: the wasm SPA
- /static :: static content
- /about
- /contact
- /health (or?)
- /db .
func WriteContentityFStreeFiles ¶
func WriteContentityFStreeFiles(IndirContentityFSs []cnty.ContentityFS)
Types ¶
type InputPathItems ¶
type InputPathItems struct {
NamedPaths []string // copied from input arg
NamedFiles []FU.FSObject // was: env.Infiles
NamedDirrs []FU.FSObject // was: env.Indirs
NamedMiscs []FU.FSObject // new
DirCntyFSs []cnty.ContentityFS // was: env.InDirFSs
AllCntys []*cnty.Contentity
}
InputPathItems is for gathering, expanding (directories), verifying, and loading files and directories specified on the command line, and then organising everything as one large array of cnty.Contentity.
- [NamedPaths] is an input slice of paths of files and directories; a path to a file that ends with "/" (or os.Sep) throws a panic
- [NamedFiles] is a slice of [fileutils.FSObject] for files named e.g. on the CLI
- [NamedDirs] is a slice of [fileutils.FSObject] for dirs named e.g. on the CLI
- [DirCntyFSs] is a slice of cnty.ContentityFS, one per element of [NamedDirs]
- [AllCntys] is an output slice of cnty.Contentity that collects all Contentities (a) named by [NamedFiles], and (b) gathered by expanding [NamedDirs] and then walking their [DirCntyFSs]
- Everything should implement interface [Errer]
FIXME: Add NamedSymls .
func DoInpaths ¶
func DoInpaths(inPaths []string) *InputPathItems
DoInpaths processes a list of paths of any type - files, directories, symlinks, "other". Its processing is pretty straightforward:
- Use input []string to generate []FSObject
- Use FSObject.IsDir (and other funcs) to append each FSObject to the correct slice: files/dirrs/miscs
- Check for errors along the way, and use the Errer embedded in each FSObject
- Resolve symlinks, appending them to files or dirrs, but keep them sandboxed by using os.Root
.
type XmlAppCfg ¶
XmlAppCfg can probably be used in other scenarios, and with various 3rd-party utilities.
type XmlAppEnv ¶
type XmlAppEnv struct {
DRP.SimpleRepo
InputPathItems
// Infiles []FU.FSObject // bye
// Indirs []FU.FSObject // bye
// IndirFSs []cnty.ContentityFS // bye
Outdir, Dbdir FU.FSObject // NOT ptr! Barfs at startup.
Xmlcatfile FU.FSObject // NOT ptr! Barfs at startup.
Xmlschemasdir FU.FSObject // NOT ptr! Barfs at startup.
// IsSingleFile is a convenience flag, and a
// result of processing CLI arg for input file(s)
IsSingleFile bool
// Result of processing CLI args -c & -s
*XU.XmlCatalogFile
PrittOutput io.Writer
// contains filtered or unexported fields
}
XmlAppEnv should be usable in other apps & scenarios too.
Source Files
¶
Directories
¶
| Path | Synopsis |
|---|---|
|
Package exec is home to functions called from m5's cli/Exec(), which is where all the "real work" gets done.
|
Package exec is home to functions called from m5's cli/Exec(), which is where all the "real work" gets done. |