| Age | Commit message (Collapse) | Author |
|---|
|
* test cases should also provide examples of how the tested external functions may be integrated into transformations
** helper templates such as "formatter" or "transformer" are an important step into this direction
** especially functions other than plain read-only functions fit much better into a template context than a XPath context
|
|
* previous logic for resolving boost::filesystem::path parameters in the XObjectValue class actively tried to resolve existing files
** this contradicts the planned introduction of e.g. a external "write-file" function
* callers of external functions with path arguments now have to enclose them in square brackets if include path resolution is required
** analog to the usage of the "xsl:import" tag
* moved "getPathFromSystemId" from compilation local method into static method of IncludeEntityResolver
* changed test cases accordingly
|
|
* FunctionReadFile is now able to distinguish between XML files and plain text files
** it selects the appropriate course of action automatically
** reading the file as XML into the DOM or reading it as a string
* the current selection criteria is the file extension
** I am thinking about trying to import every file into the DOM and using the result state of that action as selection criteria
* Updated README.md and test cases accordingly
|
|
* variables containing the output of a external function can be defined using the "select" attribute
** tree-like definition is only needed when helper templates such as "transformer" are used
** queries on variables that are instantiated in this fashion need the "self::" prefix before base nodes
* changed includes of the "testcase.xsl" base template to imports
** this signifies that the importing template is based on the imported template
** ... and this is exactly what we want to define
|
|
* the root node of the result tree of each function is a domain element
** i.e. the root node of "read-xml-file" is "file", the root node of "read-directory" is "directory"
* the root node contains the result state of the function call encoded in a "result" attribute
** possible values are "success" and "error"
** the root node may contain additional attributes such as the target path of a called transformation
* the actual function result is contained within the child nodes of the function root node
** i.e. the XML file tree returned by "read-xml-file" is a child of the function root node
** if specific errors occured they are also returned as child nodes of the function root node
*** this is currently only the case for "transform" where transformation errors are returned as "error" value node childs of the function root node
* updated test cases accordingly
|
|
* test case requires markdown.pl formatter to be available in "/usr/bin/"
* updated README.md to mention "external-text-formatter" instead of "execute"
* updated "read-directory" test case reference file
* included library resolution test into "read-file" and "read-xml-file" test cases
|
