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