aboutsummaryrefslogtreecommitdiff
path: root/test/external_text_formatter
AgeCommit message (Collapse)Author
2014-08-16Implemented primitive optional parameter support for external functionsAdrian Kummerlaender
* renamed FunctionExternalTextFormatter into FunctionExternalCommand ** the goal is to provide a general interface to a variety of external commands *** e.g. not just text formatters but system utilities for file management and so on ** this requires the stdin parameter to be optional as not all external commands require stdin input * implemented "filter_derived" helper template to determine amount of optional parameters ** optional parameters are defined as "boost::optional" specializations *** they in turn can be detected by checking if "boost::optional_detail::optional_tag" is a base class * "callConstructDocument" member method of "FunctionBase" performs additional bounds checking of parameter vector * "boost::optional<std::string>" specific member overload was added to "XObjectValue" helper class ** we will have to provide full specializations for all optional types as C++ prohibits partial member function template specialization * renamed the external function in "PlattformGuard" * changed README.md and test cases accordingly
2014-08-09Changed FunctionExternalTextFormatter to execute formatter inside shellAdrian Kummerlaender
* otherwise one has to pass the full path to the command ** additionally it is much easier to enable passing arguments to the external formatter this way * modified external function parameter accordingly * updated external text formatter test case
2014-06-30Improved "external-text-formatter" test case helper templateAdrian Kummerlaender
* 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
2014-06-25Added support for resolving non-existing pathsAdrian Kummerlaender
* 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
2014-06-15Merged "read-xml-file" and "read-file" into "read-file"Adrian Kummerlaender
* 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
2014-06-01Simplified test case result variable definitionsAdrian Kummerländer
* 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
2014-05-31Revamped external function result treesAdrian Kummerländer
* 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
2014-05-26Added "external-text-formatter" test caseAdrian Kummerländer
* 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