Age | Commit message (Collapse) | Author |
|
* 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`
|
|
* 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
|
|
* 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
|
|
* 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
|
|
* i.e. "write-file" now supports the serialization of given DOM structures
** this will be needed e.g. if FunctionTransform returns the result as a DOM tree instead of as a plain string
** enables the creation of multiple XML documents from within a single transformation
*** i.e. backports the functionality provided in XSLT 2.0 by "xsl:result-document" to xalan's XSLT 1.0
* changed test cases accordingly
|
|
* 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
|
|
* FunctionTransform was adapted to support passing the transformation as either a string path or directly as a node-set / result-tree
** this in turn required changes to the TransformationFacade
** the implementation of a xalan::XSLTInputSource specialization for the XObjectValue::get template method was also required
* changed ixslt executable to match TransformationFacade constructor changes
* these changes were implemented in preparation for a restructuring of how the separate external functions provided by InputXSLT operate and work together
** the approach up until now was to provide non-combinable external functions for distinct task such as "read a file" and "transform that transformation using these parameters into that file"
** if you think about the areas of operations of these functions are overlapping quite a bit
*** e.g. FunctionTransform reads files, transforms DOM structures and writes files instead of only transforming things
** the new approach will be to limit the feature set of each function in the attempt of making the clearer and increasing their combinability
*** e.g. FunctionTransform won't read or write files but expect both the input-DOM and the transformation-DOM as node-sets or result trees and return the transformed document as a node-set to be written using FunctionWriteFile (to be implemented)
|
|
* implemented for commit 5f6fc45 but not included into that commit
|
|
* 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
|