Somehow the previous custom deleter for xercesc::DOMDocument fails invokable assertions planet a compiler update. A lambda function with the same signature wors for some reason…
i.e. the directory tree was not correctly created in all circumstances which led to both the `generate` and `write-file` test cases failing. This was combined with some accumulated changes such as the extraction of process context instantiation.
* analogously to the projects required to actually use `InputXSLT`: Apache Xalan and Xerces
* both the `Sequence` and `IndexSequence` helper templates were developed prior to C++14 * as the new standard covers exactly the functionality provided by these templates they should be replaced ** they are used as indexes to the _Xalan_ parameter array in `FunctionBase`
* e.g. member functions defined in the class definition are implicitly marked `inline`
* this is possibly a breaking change for all applications built on either `FunctionExternalCommand` or `FunctionReadFile` ** e.g. meta datasource XPath queries in _StaticXSLT_ will have to be changed to accomodate this * the reason for doing this was to fix the behaviour when reading namespaced XML files ** e.g. XSL stylesheets could only be queried with a clunky XPath expression such as `$transformation/self::*[name() = 'xsl:stylesheet']` instead of simply `$transformation/self::xsl:stylesheet` *** this was caused by the now activated namespace comprehension in `xercesc::XercesDOMParser` which is disabled by default *** it caused all local node names to be converted into their namespace prefixed version, e.g. `local-name()` returned `xsl:stylesheet` instead of `stylesheet`
* `FunctionExternalCommand` failed to offer correct output handling when provided with a valid XML document which included a XML declaration ** `xerces::XercesDOMParser` generated the appropriate errors but they were not handled by `FunctionExternalCommand` ** wrapping is not necessary for full XML documents but is required for invalid XML as returned by e.g. common _Markdown_ processors *** if wrapping is applied to full XML documents which include a XML declaration the parser and subsequently the complete external function fails * added error parser handling by making the compilation unit local `importDocumentElement` method return value optional * added XML declaration detection and handling to `readOutput` ** if XML declaration is detected no wrapping is applied * added wrapping detection in `FunctionExternalCommand::constructDocument` ** if no wrapping is detected the whole tree is returned as content instead of just returning its child nodes
* long outputs to stdout from child processes filled up the `boost::process::pistream` buffer and caused `write` to block ** this issue was circumvented by reading the stream into a `std::stringstream` instance before retrieving the blocking exit status * modified document import implementation accordingly
* this is required to be able to resolve paths contained within a file relative to its location ** which is in turn needed to enable BuildXSLT modules without requiring the module transformations to be resolved using IncludeEntityResolver
* this changes filesystem context resolution for external function execution to be relative to the working directory ** this was changed to enable module support in BuildXSLT *** ... which is in turn required as a foundation for extracting the detail transformations into a separate "StaticXSLT" application * added parameter-less FilesystemContext constructor which defaults to the working directory
* i.e. it now supports reading transformations from either a file or stdin
* updated dependencies to mention C++14
* i.e. InputXSLT now requires a C++14 supporting compiler / standard library implementation * this was done while enabling the StreamInputSource to handle all kinds of streams ** this in turn is required to enable e.g. stdin as transformation source while preserving the correct filesystem context
* doctypeSystem and doctypePublic were mixed up
* this change was needed so that one is able to apply transformations located in e.g. a central directory as if they where located in the working directory ** otherwise e.g. the BuildXSLT transformation would have to be copied into every project that requires it * implemented StreamInputSource wrapper for boost::filesystem::ifstream and xalan::XSLTInputSource ** this is needed because the boost::filesystem::ifstream instance has to exist as long as the xalan::XSLTInputSource it is bound to ** i.e. a simple helper function to instantiate the source and set the working directory would have not been sufficient
* otherwise include entity resolution fails for node-based xalan::XSLTInputSource instances instantiated by the XObjectValue class
* if the target parameter is not provided FunctionGenerate now performs exactly the same functionality as FunctionTransform * added "boost::optional<boost::filesystem::path>" specialization to the XObjectValue class * modified test cases accordingly * modified README.md accordingly
* changed the XObjectValue constructor to accept a pointer to FilesystemContext instead of instantiating the context by itself * the FilesystemContext is now instantiated in the "callConstructDocument" member method of "FunctionBase" ** a const reference to FilesystemContext is passed to all "constructDocument" member method implementations * the FilesystemContext is currently only used by FunctionExternal command to set the correct work directory in "boost::process::context" ** this is required so calling external commands from inside a stylesheet works as expected *** i.e. from inside the directory the stylesheet is located in * modified all remaining external function implementations accordingly
* this change was implemented to match the naming scheme of all other external functions * updated external text formatter test case accordingly
* the minimum count of parameters to a external function is the maximum parameter count minus all optional parameters * updated error message of "FunctionBase" member method "getError" to reflect the newly implemented possibility of optional parameters
* 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
* 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
* FilesystemContext was returning absolute paths in nearly every situation ** even when a path relative to the current working directory might be easier on the eyes * new _soft_ base path resolution logic is implemented in a local "determineBasePath" method
* i.e. they now create the directory tree required to contain their respective output files automatically * this is needed so TestXSLT is able to create the target directory implicitly
* entities in transformations passed by DOM to FunctionGenerate or FunctionTransform require a valid system id as a FilesystemContext base to be resolved * added getBase member method to FilesystemContext
* its called a "platform" and not a "plattform" as in German...
* TestXSLT is a playground for testing static site generation concepts based on InputXSLT * replaced xalan::FormatterToXML indent amount with its default value
* the base path of entities resolved through square bracket include paths was not resolved correctly due to missing extraction
* added custom deleter for xalan::XalanCompiledStylesheet specific std::unique_ptr specialization * added previously missing check for successful stylesheet compilation
* this function essentially provides the same functionality as FunctionTransform with the addition of directly committing the result to the filesystem ** this is needed if one wants to generate doctype-containing transformations from inside a transformation as "write-file" is not able to infer the doctype of a given xalan::XalanNode pointer ** this is a integral limitation of (at least) XSLT 1.0 as implemented in Apache Xalan *** a document can of course only have a single document type *** e.g. we can not include a doctype node in the result tree of FunctionTransform * implemented test case for FunctionGenerate * transformation "test.xsl" is shared between the FunctionTransform and FunctionGenerate test cases * modified README.md accordingly
* they don't modifiy the class state so there is no reason for them not being marked as const ** all calling methods are also const ** this enables us to remove the const_cast in FunctionBase * modified external function implementations accordingly * inlined handleError method in FunctionTransform as it is not needed in multiple places anymore
* "xsl:output" was disregarded for xalan::FormatterToXML based output ** the setting contained within this tag have to be passed manually to the constructor... ** the xalan standard implementation includes special handling for this case ** sadly there was no alternative to adding special handling in InputXSLT as well, it is really quite ugly * added "dispatchTransformer" template member method to TransformerFacade ** calls xalan::FormatterToXML augmentation logic if needed, compiles template * this problem also exists for FunctionTransform output to xercesc DOM ** this patch doesn't aim to fix it in that case, it will have to be fixed separately
* previous createDocument method used default name "content" ** this led to problems when using xalan::XalanNode as transformation input ** the parameter-less createDocument overload now creates a unnamed xercesc::DOMDocument * changed external function implementations accordingly
* paths that can not be resolved against the include-path vector were passed on as they were instead of first removing the "file://" prefix * this caused all normal entity paths passed to "xsl:import" and "xsl:include" statements to be unresolvable
* the common use case of ResultNodeFacade inside external function implementations is managing the result root node ** this root node can be fetched through the xercesc::DOMDocument instance ** the new alias overload automatically fetches the root node pointer and as such doesn't require a root node parameter * changed external function implementations accordingly
* pointers to xercesc::DOMDocument were manually released ** this is now solved using a custom deleter for the appropriate std::unqiue_ptr template specialization * added matching factory method to DomDocumentCache * updated external function implementations accordingly ** "constructDocument" is now expected to return a DomDocumentCache::document_ptr instance * updated TransformerFacade accordingly * this change was implemented to get rid of the manual memory management required by xalan / xerces
* as FunctionTransform returns the result as a DOM tree there is no reason for including the separately tested FunctionWriteFile in this test case
* FunctionTransform now accepts xalan::XalanNode base xalan::XSLTInputSource instances as input parameter ** such xalan::XSLTInputSource instances were already supported for the stylesheet parameter but not for the input parameter ** e.g. it is now possible to generate a DOM inside a transformation, pass the DOM into a embedded transformation as input, modifiy the output of that transformation, pass this modified DOM into another transformation and so on... you get the point * this required a revamp of TransformationFacade ** it is now a transformation independent wrapper for xalan::XalanTransformer *** as such is was renamed to TransformerFacade ** removed error catching template factory method "try_create" as it is not needed anymore ** "std::basic_ostream<char>&" taking "generate" member method overloads were removed ** the set of "generate" member overloads was reduced to two methods accepting xalan::XSLTInputSource and xalan::FormatterListener as parameters * the core problem first documented in 299d0f6 was solved by transforming the input parameter into a xerces DOM and wrapping this DOM inside a xalan::XercesDOMWrapperParsedSource instance * serialization of the transformation result for file / std::cout output is now performed directly by the ixslt frontend * removed 'stylesheet parameter' parameter from FunctionTransform ** the functionality provided by this is easily replicated using the now possible DOM input parameter ** this was done to simplify the interface and reduce unnecessary feature duplication * updated FunctionTransform test case accordingly * added "generate" template function to ixslt frontend ** wraps TransformerFacade and manages ist input arguments ** handles serialization to stream * this commit marks a important milestone towards the goals defined in 741a70f
* using xalan::FormatterToXercesDOM internally ** this required changes to the TransformationFacade::generate member method overloads * TransformationFacade::generate now accepts references to xalan::FormatterListener instances ** "generate(std::basic_ostream<char>&..." instantiates a xalan::FormatterToXML and passes it to the actual generate member method * changed ResultNodeFacade's "getNode" method into a "getResultElement" method ** xalan::FormatterToXercesDOM requires a xercesc::DOMElement instance instead of the previously available xercesc::DOMNode instance ** changed FunctionReadDirectory accordingly * adapted FunctionTransform test case accordingly
* neither the constructor nor the generate member methods need to be templatized ** only supported "output" argument is now a reference to a "std::basic_ostream<char>" instance ** the caller is responsible for e.g. writing the output to disk * this was done to simplify the basic interface of InputXSLT * removed "default_params" testcase along with default parameter generation ** this feature is neither used nor required