Repository of Scripts

The parse tree conforms to the following logic structure that matches to the XML one exactly:

• name-of-XML-element[]: all elements that share the same parent node and the same name name-of-XML-element are put into an array of nodes whose name is the name of the XML element.
  If the element is alone, the structure doesn't change and the array contains the element only.
• name-of-XML-attribute: the value of the attribute is assigned to a folder of the parse tree, which stands as a child of the owner element and whose name is the name of the attribute.

Please note that an XML identifier admits '.' and '-' characters, which are rejected by CodeWorker in an identifier. So, these characters are degenerated in underscores.

The parse tree conforms to the following logic structure:

• comment (optional) holds the last comment block found into the DTD before the first DTD element, if any. This comment is interpreted as an explanation on what the DTD is for.
• listOfElements[] contains the list of all "<!ELEMENT" nodes encountered:
  • comment (optional) holds the comment block that stands just before the element description in the DTD, if any.
  • category (optional) is worth "EMPTY" or "ANY".
  • composite (present if and only if category doesn't exist)
    • multiplicity (optional) is worth '?' or '*' or '+'
    • nodes put into the array (composite[]):
      • operator (present on each node, except the last one) is worth ',' or '|'
      • constant (one and only one field amongst constant and element and composite) is worth "#PCDATA"
      • element name of an element
        • multiplicity (optional) is worth '?' or '*' or '+'
      • composite recursive structure
  • listOfAttributes[] contains the list of all attributes belonging to the element (one and only one amongst type, listOfEnums and constant):
    • type is worth "CDATA" or "ID" or "IDREF" or "IDREFS" or "NMTOKEN" or "NMTOKENS" or "ENTITY" or "ENTITIES" or "NOTATION"
    • listOfEnums list of enumerated values
    • constant a constant value
    • value (optional, constant must be populated) is worth "#IMPLIED" or "#REQUIRED" or "DEFAULT" or "FIXED"
• listOfEntities[] contains the list of all "<!ENTITY" nodes encountered.
  • comment (optional) holds the comment block that stands just before the entity description in the DTD, if any.
  • external (optional) is worth "SYSTEM"
  • constant is the value of the entity after resolution of references to other entities.

It recognizes some XSL elements (not all yet), such as:

• xsl:template
• xsl:foreach
• xsl:value-of
• xsl:sort
• xsl:when
• xsl:choose
• xsl:otherwise

XPath is parsed completely according to the specifications for XSLT 1.0.

Two properties must be passed on the command line:

• SOURCES gives the file masks of C++ bodies to select for the transformation. If more than one mask, one cancatenates them, separated by a semi-comma.
• RAW_PROFILING_DIR provides the directory where to generate the profiling module. The profiling module manages the time spent in each profiled function and how many times they have been called.

The profiling module is implemented in files "RawProfiling.h" and "RawProfiling.cpp".

Here, no parsing is processed for recognizing the signature of functions and the body. So, some troubles might appear if a #define macro describes a part or the whole of the function.

One activates the profiling by setting the preprocessor definition RAW_PROFILING at compile-time (-D RAW_PROFILING on the command line of the C++ compiler).

To make it simple, the header of the profiling module is inserted after the first #include encountered. It may cause some troubles if the first include is put in a conditional preprocessing block (#ifdef WIN32 ... #endif/#else).

The body of the function starts by incrementing its assigned counter held by the profiling module and by timing the visit of the controlled sequence.

Note that the transformation can be applied more than once: the second pass will not affect the source file.

Each function scanned for the profiling has both a counter and a chronograph assigned. The chronograph holds the total time spent in the function.

The display of result is the simplest that may exist: functions are listed with the number of calls and the total time (RawProfiling::displayResults()).

The file to generate is "RawProfiling.cpp" and will be put in RAW_PROFILING_DIR.

The source file is highlighted and keywords plus particular symbols of the language are linked to the online-documentation.

Note that this.docURL designates the URL or the directory where both the CSS and the HTML documentation of CodeWorker are stored. If not populated, it will resolve links from the directory where is the target HTML file. Don't forget to end the URL or directory with a trailing slash.

If this.includeCSS is set to a path, the styles are included into the HTML file from the path, rather that being linked to a file while browsing.

To highlight any script, type:

CodeWorker -translate CWscript2HTML.cwp <CW-script.cw> <CW-script.html>

CodeWorker -translate CWscript2HTML.cwp <CW-script.cw> <CW-script.html> -insert docURL HTML-doc-URL

It is expressed in the extended-BNF dialect of CodeWorker, so has the advantage of running under CodeWorker for scanning scripts, and has the original feature to be auto-descriptive.

• _REQUEST["country"] is worth "Finland"
• a global variable country is declared and is worth "Finland".

Format:
hitCounter ::= [remote_host]*
remote_host ::= "host" hostNameAsString '{' [date_split]* '}'
date_split ::= DATE numberOfHits

The parse tree:

• hits: total number of hits
• hosts[]: list of all remote hosts
  • hits: total number of hits for this remote host
  • dates[]: hits by date for this remote host
    • hits: total number of hits for this remote host at this date
• dates[]: list of all dates
  • hits: total number of hits for this date