| Age | Commit message (Collapse) | Author |
|---|
|
* 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
|
|
* 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)
|
|
* 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
|
|
* 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
|
|
* 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
|
|
* 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
|
|
* 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
|
|
* 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
|
|
* test case base template contains the basic test case markup
** it was mostly created to include include-path resolution into the test cases
* improved transformer helper template by separating the external function call into its own variable
|
|
* added basic "transformer" wrapper template to call "InputXSLT:transform"
** this removes the need to specifiy arguments in a separate xslt variable
|
|
* 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
|
|
* "InputXSLT:transform" expects two input arguments and executes the given transformation into the given target file
** this function respresents a important step in the direction of making it possible to write an actual static site generator on top of InputXSLT using XSLT
* added basic "transform" test case
* updated README.md to include this new function
|
