Elego ComPact Manual Set Version 1.2
Prev Next

Chapter 14. The HTTPdActions file

Note: This part of the documentation is rather old and needs review and update. A paragraph about definition preferences has been added to describe some recent extensions, though.

The HTTPdActions-file has the following Syntax:

   [file]  ::=  *([definition][newline])

   [definition] ::= [comment] | [actwd] | [action]

   [comment]    ::= '#'[chars]
   [actwd]      ::= 'wd ' +([text])
   [action]     ::= 'action ' [text] ([text] | [redirection] | [delegation])
   [redirection]::= 'via_path(' [text] ')'
   [delegation] ::= 'prefer' 'internal' 'else' [text]
                 |  'prefer' 'package_default' 'else' [text]


Global variables in text-constants will be substituted by its value if used in form of a variable-application [varappl]

   [varappl] ::= '${'[variable]'}'


Much the some, field-applications [fieldappl] are expanded by their actual value given by further arguments of the Execute-Path. We differ three forms of field-applications. Every expansion is done at runtime when the Execute-Path and its corresponding command is interpreted. Let be [field] = [variable]:

   [fieldappl] ::=  '{?'[field]'}'   -- field may exist in Execute-Query
               |    '{:'[field]'}'   -- field must exist in Execute-Query
               |    '{!'[field]'}'   -- field must exist in Execute-Query *and* 
                                        compress(field) must not be equal to ""


Every action-definition [action] is relative to the preceding working-directory-definition [actwd] (where the default is "."). The execution of the corresponding command will be done within this working directory. The components of the working-directory-definition will be concated via Pathname.Join and evaluated at execution time.

For the sake of more flexible HTML-form-usage we allow the command-definition of any actions to be given not only by text-constants but also via the redirection of a new Path. When executing such an action, the Path will be expanded and then interpreted as having received directly from the client. (Be careful, path-cycles will not be detected!)

To get a more concrete feeling, we present the following extract of a HTTPActions-file: (Note, the designer of the HTML-pages has to take care for the consistency of HTTPActions-file and all used HTML-pages.)

action  "Edit"            via_path("Edit?F={?F}&Wd={!Wd}")
action  "Load"            via_path("Load?F={?F}&Wd={!Wd}")

wd      "${collection}" 
#----------------------
action  "NewCollection"   "pkgm -newcollection {:Collection}"
action  "NewPackage"      "pkgm -newpackage {!Package} {:Kind}"
action  "Checkout"        "pkgvm -checkout {!Tag} {:Package}"

wd      "${collection}" "${package}"
#-----------------------------------
action  "Build"           "pkgm -build"
action  "Depend"          "pkgm -depend"
action  "Clean"           "pkgm -clean"
action  "ShipAs"          "pkgm -shipas {!Version} {:Pool}"
action  "Difference"      via_path("Load?Page=Error&ErrorText=Not+yet+implemented&ErrorHint=Difference")
action  "Merge"           via_path("Load?Page=Error&ErrorText=Not+yet+implemented&ErrorHint=Merge")

wd      "${projects}" "${project}"
#---------------------------------
action  "PrjmClean"                 via_path("Execute?Action=PrjmClean{!Doit}")
action  "PrjmCleannot really"       "prjm -clean"
action  "PrjmCleanreally"           "prjm -realclean"
action  "PrjmDependencies"          "prjm -dependencies"
action  "PrjmCheckout"              "prjm -checkout '{:Shot}'"


Action definition preferences . The actual definition of an action may be taken from another source than the HTTPdActions file. Currently there are two possibilities: Several actions may be defined simply by an internal implementation of ComPactHTTPd, while others (usuallly package-related commands) may be taken from the PkgBase.DefaultData resource. This is expressed by the statements

prefer internal else

prefer package_default else

introducing the action definition. The first firm is used in the shipped HTTPdActions file as default for all actions that have internal implementations for efficiency reasons, but which a user might want to override or customize. The second form is handy for all package related actions, as these usually depend on the package kind and are already defined in the PkgBase.DefaultData resource. This chapter is completed by a short example of these features. 

wd      "${Context}"
#-----------------------------------
action  "Build"           prefer package_default else "pkgm {?optForce} {?optVerbose} {?optDebug} {?optQuiet} -gui -build"
action  "Depend"          prefer package_default else "pkgm {?optForce} {?optVerbose} {?optDebug} {?optQuiet} -gui -depend"
action  "Clean"           prefer package_default else "pkgm {?optForce} {?optVerbose} {?optDebug} {?optQuiet} -gui -clean"
action  "RealClean"       prefer package_default else "pkgm {?optForce} {?optVerbose} {?optDebug} {?optQuiet} -gui -realclean"

action  "Log"             prefer internal else "pkgvm {?optVerbose} {?optDebug} {?optQuiet} -log"
action  "Commit"          prefer internal else "pkgvm {?optVerbose} {?optDebug} {?optQuiet} -commit {:CommitType}"
action  "Release"         prefer internal else "pkgvm {?optVerbose} {?optDebug} {?optQuiet} -release {:CommitType}"
action  "Tag"             prefer internal else "pkgvm {?optVerbose} {?optDebug} {?optQuiet} -tag {:Tag}"
action  "Update"          prefer internal else "pkgvm {?optVerbose} {?optDebug} {?optQuiet} -update {:Tag}"
action  "Difference"      prefer internal else "pkgvm {?optVerbose} {?optDebug} {?optQuiet} -udiff {?F}"


Prev Home Next
ExHTML Expressions Up Syntax and Semantics of ComPactHTTPd requests