| Age | Commit message (Collapse) | Author |
|---|
|
* `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
|
|
* 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
|
|
* 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
|
|
* 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
|
|
* 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
|
|
* 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
|
|
* added support for defining boost::filesystem::path as a external function parameter
** boost::filesystem::path parameters are resolved against the appropriate FilesystemContext and IncludeEntityResolver instances
* xalan::XSLTInputSource parameter source paths are also resolved
* removed need for passing a reference FilesystemContext to "constructDocument" methods
** they now only accept the parameters of the external function implemented by them
** all path resolution logic is wrapped by the newly created XObjectValue class
* converted XObjectValue namespace into class
** the "get" template method is now a template member method
** this was needed to enable value casting logic to access the appropriate FilesystemContext and IncludeEntityResolver instances
* this commit marks the next step towards the goals defined in 741a70f
|
|
* "unsigned" type led to a compiler error on 64bit systems
** the Sequence template uses std::size_t which resolves to "unsigned long" instead of "unsigned int" on 64bit systems
** as "unsigned" is resolved to "unsigned int" by the compiler this situation produced a type conflict
* added recommendation for using a xalan library version built with ICU flags to README.md
** otherwise e.g. the "format-number" function is not fully supported
|
|
* extracted system id handling into separate "resolve" method overload of "IncludeEntityResolver" class
* paths to be resolved against the include path vector are enclosed by square brackets
** FilesystemContext for external functions was instantiated using the unmodified systemId provided by xalan::Locator
** this commit adds include path resolution to that step
*** exceptions were thrown as the program tried to instantiate a FilesystemContext instance without resolving the square bracket syntax
* changed FunctionTransform "target" attribute content to the target path filename instead of the full path
|
|
* external DOM may cause xercesc::DOMException's to be thrown instead of passing all errors to the custom error handlers
** these exceptions are handled by this commit by setting the "result" attribute to "error" and adding "error" value nodes with further information
|
|
* replaced std::tuple constructing Mapper template methods with direct XObjectArgVectorType unpacking
** XObjectValue::get template method is applied directly using parameter pack unpacking
* implemented custom IndexSequence / Sequence type to provide vector indexes
* modified all external functions to provide matching constructDocument overloads
|
|
* if a given file can not be located relative to the transformation's location both "read-file" and "read-xml-file" will now try to resolve the path using the IncludeEntityResolver
* all external functions based on the FunctionBase template are now provided with a pointer to a IncludeEntityResolver instance
* it is determined by the external function implementation whether include path resolution will be used
|
|
* names matter, from now on parameters to external functions will be called parameters uniformly instead of mixing arguments and parameters
|
|
* the given XObject is passed to the called transformation
** this was done to enable templates to pass information to each other
** this should support any type usable in a XPath context to be passed as an argument
* expanded FunctionTransform test case accordingly
|
|
* FunctionBase::argument_tuple is a std::tuple specialization type specialized on the argument types passed inside the variadic template argument of FunctionBase
* added tuple Mapper and XObjectValue helper namespaces containing recursive tuple construction and XObjectPtr value extraction logic
* changed all external function implementations accordingly
* this change was implemented to uniformly support different external function argument types than std::string
|
|
* external functions may expect arguments with a type different from boost::filesystem::path so they are only provided raw string values
* moved xalan string conversion logic into separate compilation unit
|
|
* constructDocument member method is provided with a FunctionBase::argument_array instance
* improved argument validation in FunctionBase
* this parameter was added to support FunctionBase as a base class for FunctionTransform
|
|
* using std::unordered_map for named cache lookups was a nice idea but is not useful when one keeps in mind that:
** we don't want cached external function responses in a situation where we are able to execute transformations inside transformations
** cached responses mean that we can not read a xml file, overwrite it using another transformation and then read it again
* the currently available InputXSLT frontend only processes a single transformation anyway, so increased memory requirements should not pose a problem
** if a future frontend should offer batch processing of transformation tasks, one could implement a cache reset method to free memory after a transformation has been processed
|
|
* as the xerces document is not instantiated by DomDocumentCache::item and the class only exports a pointer to the converted xalan document, it makes no sense to expose the class to the outside in the first place
|
|
* common parts were moved into CRTP template base class _FunctionBase_
* all external functions are derived from that class
** only have to implement _constructDocument_ member method
** currently only supports a single string input parameter which is enough for now
* this change condenses external funtion implementations to the essential and should increase readability as well as maintainability
|
