| 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`
|
|
* e.g. member functions defined in the class definition are implicitly marked `inline`
|
|
* 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. 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
|
|
* 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
|
|
* 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
|
|
|
|
* 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
|
|
* the base path of entities resolved through square bracket include paths was not resolved correctly due to missing extraction
|
|
* 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
|
|
* 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
|
|
* 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)
|
|
* if a square bracket enclosed path can be extracted but not resolved against the include path vector we should return at least the extracted path and not the raw path
* otherwise the system has no chance of correctly resolving things
** additionally error messages were showing the square bracket syntax instead of the actual path
|
|
* 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
|
|
* 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
|
|
* in difference to ErrorCapacitor this class doesn't throw an exception on "discharge" but returns the gathered warnings
* adapted FunctionTransform and frontend error handling to include warnings
* added static "try_create" method to TransformationFacade
** wraps construction error handling
** custom logic may be embedded using the std::function argument
*** this was implemented to prevent unneccessary code duplication for handling both construction and generation errors
* adapted FunctionTransform to return warning as "warning" nodes in the result tree
** added functional lambda expression factory method "handleErrors"
*** returns a error handling lambda expression for a given ResultNodeFacade
* implemented WarningGuard class in frontend executable
** guarantees warnings to be printed to std::cerr independent of any exceptions
|
|
* ErrorMultiplexer is derived from both xercesc::ErrorHandler and xalan::ProblemListener
* registers itself as XalanTransformer's ErrorHandler and ProblemListener
* distributes captured errors and warnings to all registered ErrorMultiplexer::Receiver instances
** ErrorCapacitor implements the ErrorMultiplexer::Receiver interface and as such registers itself in a given ErrorMultiplexer instance
** ErrorMultiplexer reduces the different xalan and xercesc internal error classifications into either warnings or errors
* this was implemented to make it possible to easily differentiate between warnings and errors
** previously warnings were treated as errors
** ErrorCapacitor ignores warnings and only captures errors
** WarningCapacitor will be implemented to handle warnings during XSLT processing
|
|
* added entity, line and column information
* formatting analog to ErrorCapacitor warning messages
** i.e. this commit implements functionality similar to "xalanc::ProblemListenerBase::defaultFormat" for "xercesc::ErrorHandler" exceptions
|
|
* the root node of the result tree of each function is a domain element
** i.e. the root node of "read-xml-file" is "file", the root node of "read-directory" is "directory"
* the root node contains the result state of the function call encoded in a "result" attribute
** possible values are "success" and "error"
** the root node may contain additional attributes such as the target path of a called transformation
* the actual function result is contained within the child nodes of the function root node
** i.e. the XML file tree returned by "read-xml-file" is a child of the function root node
** if specific errors occured they are also returned as child nodes of the function root node
*** this is currently only the case for "transform" where transformation errors are returned as "error" value node childs of the function root node
* updated test cases accordingly
|
|
* xalan::ProblemListenerBase provides a static member method called "defaultFormat"
** this method provides formatting of problem messages into xalan::XalanDOMString instances when combined with xalan::DOMStringPrintWriter
* there is no need for implementing custom message formatting
** the only reason why ErrorCapacitor exists is so we are able to capture and print messages at our own volition
|
|
* ErrorHandler is replaced by ErrorCapacitor
** temporarily registers itself as both the ProblemListener and ErrorHandler of a given XalanTransformer instance
** deregisters itself on destruction
** collects all problems and errors during its lifetime inside a internal std::vector<std::string> instance
** if this instance is not empty it is thrown contained within a ErrorCapacitor::exception by the member method ErrorCapacitor::discharge
* this enables using the same code for handling transformation compilation and generation errors and problems
* updated test frontend accordingly
|
|
* xalan is segfaulting in XalanDOMString constructor when the static member "XalanLocator::getSystemId" is returning null-pointer
** this should seemingly be handled by passing a pointer to the static constant m_dummy but this sadly fails to prevent the segfault
** the patch provided by this commit fixes the problem for now but I cannot guarantee that this wont cause any side effects in a other context
* Adapted TransformationFacade to handle errors during transformation compilation
** errors generated during transformation compilation are returned through the generate member method
** throwing an exeception during TransformationFacade construction would require additional error handling in the calling code
* Added xalan::ProblemListener functionality to the ErrorHandler class
** XSLT problems passed to the ProblemListener are returned alongside to and treated as all other transformation errors
|
|
* ErrorHandler class created in 5859cb6 now caches all errors instead of pushing them to std::cerr
** cached errors are retrieved by TransformationFacade's "generate" member method
* test frontend pushes all errors to std::cerr
* FunctionTransform returns errors to the calling template as XML
** FunctionTransform test case demonstrates how one may test for successful transformation
* "generate" member method returns std::string vector wrapped in a std::unique_ptr
** this is used as a kind of optional pointer, as the std::unique_ptr instance only wraps a vector if errors where actually generated
|
|
* std::string specialization of "get" template method
* replaces FunctionTransform local input trimming implemented in 5859cb6
|
|
* InputXSLT::ErrorHandler is derived from xercesc::ErrorHandler and enables contextual printing of transformation errors
** currently this means that the error messages passed to std::cerr contain the full path of the offending transformation
* added input trimming to the external transform function
** calls to this function from inside a transformation may contain unnecessary whitespace characters which disrupt further processing
|
|
* there are situations where one may pass absolute paths to external functions which should not be resolved against the context path
** for example when reading files found by "read-directory" through its "full" value node
* this could be checked by the external functions themself
** but as this check is required by all of them it is better implemented in the FilesystemContext
|
|
* wraps result node construction and appends it to root node on destruction
* offers a simpler interface for common node construction patterns
* simplifies result node construction in all external function implementations
** most noticeable in FunctionReadDirectory
* expanded FunctionReadDirectory result nodes by name, extension, and full-path nodes
|
|
* replaced ranged for loop with more appropriate std::for_each
|
|
* std::vector<FilesystemContext> instance is now const
** this required a constructor change
* marked resolve member method as const as it doesn't need to modify anything
** this is also true for the overloaded resolveEntity member method
** the base class xercesc::EntityResolver prevents us from marking it as such
|
|
* InputXSLT is dependent on boost anyway, so there is no argument to be made to emulate boost::optional using std::pair
|
|
* enables access to include path resolution from external functions
** this will be useful to enable reading files from the include path using the external read-file or read-xml-file functions
* moved file path extraction into a function local to the compilation unit
|
|
* xalan / xerces offers the possibility of implementing custom entity resolvers which are called upon by "<xsl:include..."
** such a custom resolver was implemented to resolve include path entities
* this is a much better way to support include paths than offering a custom external "resolve-include" function
* as entity paths are expanded before they are passed to the entity resolver, a special "[path]" syntax simmilar to "#include <path>" had to be implemented
|
|
* 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
|
|
* order of items in a directory was varying across platforms which hindered testability
* they are now temporarily copied into a std::vector instance and then sorted using std::sort
* updated "read_directory" test case reference file accordingly
|
|
* 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
|
|
* removes responsibility for clearing parameters from the generate member methods
* abstracts parameter escaping and setting and handles map conversion
* marked actual generate member method as private and added StylesheetParameterGuard reference argument
** "frontend" generate member methods instantiate a StylesheetParameterGuard instance and pass it to the actual generate method
** this enables central default parameter definition while offering the possibility for custom parameters
|
