| Age | Commit message (Collapse) | Author |
|---|
|
* this change was implemented to match the naming scheme of all other external functions
* updated external text formatter test case 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
|
|
* otherwise one has to pass the full path to the command
** additionally it is much easier to enable passing arguments to the external formatter this way
* modified external function parameter accordingly
* updated external text formatter test case
|
|
* 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
|
|
|
|
* i.e. they now create the directory tree required to contain their respective output files automatically
* this is needed so TestXSLT is able to create the target directory implicitly
|
|
* 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
|
|
* its called a "platform" and not a "plattform" as in German...
|
|
* TestXSLT is a playground for testing static site generation concepts based on InputXSLT
* replaced xalan::FormatterToXML indent amount with its default value
|
|
* the base path of entities resolved through square bracket include paths was not resolved correctly due to missing extraction
|
|
* added custom deleter for xalan::XalanCompiledStylesheet specific std::unique_ptr specialization
* added previously missing check for successful stylesheet compilation
|
|
* 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
|
|
* "xsl:output" was disregarded for xalan::FormatterToXML based output
** the setting contained within this tag have to be passed manually to the constructor...
** the xalan standard implementation includes special handling for this case
** sadly there was no alternative to adding special handling in InputXSLT as well, it is really quite ugly
* added "dispatchTransformer" template member method to TransformerFacade
** calls xalan::FormatterToXML augmentation logic if needed, compiles template
* this problem also exists for FunctionTransform output to xercesc DOM
** this patch doesn't aim to fix it in that case, it will have to be fixed separately
|
|
* 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
|
|
|
|
* as FunctionTransform returns the result as a DOM tree there is no reason for including the separately tested FunctionWriteFile in this test case
|
|
* 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
|
|
* neither the constructor nor the generate member methods need to be templatized
** only supported "output" argument is now a reference to a "std::basic_ostream<char>" instance
** the caller is responsible for e.g. writing the output to disk
* this was done to simplify the basic interface of InputXSLT
* removed "default_params" testcase along with default parameter generation
** this feature is neither used nor required
|
|
* test cases should also provide examples of how the tested external functions may be integrated into transformations
** helper templates such as "formatter" or "transformer" are an important step into this direction
** especially functions other than plain read-only functions fit much better into a template context than a XPath context
|
|
* this increases consistency accross all external functions
* enables usage of non-global formatter executables
|
|
* 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
|
|
* the external "transform" function now expects a input document as its first parameter
** this input parameter is resolved and passed as input to the transformation
** changed and expanded test case accordingly
* because of xalan internal problem this currently only supports input DOMs loaded directly from the fs
** passing result trees or node sets analog to how the transformation may be passed into the function leads to parsing and assert failures
** parsing node-based input DOMs using xalanc::XalanTransformer::parseSource produces errors concerning base entity resolution
** if the error capacitor instance is temporarily disabled it works correctly as long as one doesn't try to access the input document
*** this causes a assert failure in the XPath implementation (seems to be related to XALANC-540)
|
|
* outdated documentation led me to believe that one has to free compiled stylesheets and input sources manually
** while xalan::XalanTransformer offers the required methods it also calls them by itself on destruction
|
|
|
|
* slightly improved FunctionTransform test case utility templates
|
|
* accepts a path parameter and the content to be written
* removed target parameter form FunctionTransform
** transformation result is now returned as a string
*** nodeset return value is planned
** e.g. writing the result to the fs is optional and has to be achieved using FunctionWriteFile
* changed "transform" test case accordingly
* this marks a paradigm shift and is the continuation of the changes described in 741a70f
** InputXSLT now also implements a output function
* added basic io error handling to FunctionReadFile
|
|
* 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)
|
|
* FunctionReadFile is now able to distinguish between XML files and plain text files
** it selects the appropriate course of action automatically
** reading the file as XML into the DOM or reading it as a string
* the current selection criteria is the file extension
** I am thinking about trying to import every file into the DOM and using the result state of that action as selection criteria
* Updated README.md and test cases accordingly
|
|
* "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
|
|
* 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
|
|
* a single file may be passed to the XSLT processor as input
** the file is read once and stored within a xalan::XalanParsedSource to be reused by all calls to "TransformationFacade::generate"
* added appropriate TranformationFacade constructor overload
** this new constructor overload which is taking a path to both the transformation and the input file is the main constructor
*** the old constructor is now only a alias for this new constructor
* adapted static "try_create" TransformationFacade factory method into variadic template factory method
* added optional "--input" argument to ixslt
** expanded option handling accordingly
|
|
* 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
|
|
* 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
|
|
* improved "ixslt" frontend code structure
** extracted input, process and output logic into separate methods
** removed manual "--transformation" parameter check as it is defined as required
|
|
|
|
* removes xalan and boost::filesystem::fstream dependencies from FunctionReadXmlFile
* xercesc provides a solution for loading files into it's XercesDOMParser class
** this should be used instead of building a custom replacement using boost's fstream and xalan::XSLTInputSource
|
|
* 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
|
|
* variables containing the output of a external function can be defined using the "select" attribute
** tree-like definition is only needed when helper templates such as "transformer" are used
** queries on variables that are instantiated in this fashion need the "self::" prefix before base nodes
* changed includes of the "testcase.xsl" base template to imports
** this signifies that the importing template is based on the imported template
** ... and this is exactly what we want to define
|
