| Age | Commit message (Collapse) | Author |
|---|
|
* 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)
|
|
* 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
|
