| Age | Commit message (Collapse) | Author |
|---|
|
* 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
|
|
* resolves paths provided as strings against include paths provided through the newly created "--include" argument of the test executable
* this was implemented to enable central collections of XSLT libraries simmilar to how there are C headers in "/usr/include"
|
|
* added "std::basic_ostream<char>" taking "generate" member method overloads
* marked cli parameter "target" as optional
** output is streamed to std::cout if target file is not provided
|
|
* the transformation is now provided with default parameters such as the target file and its parent directory
* added appropriate test case
** default_params
* test frontend now doesn't provide a "test" parameter anymore
* extracted parameter setter into separate member method "setParameters" of TransformationFacade
|
|
* selectively testing document construction in plain C++ code has turned out to be more work than worth it
** i.e. removed test cases and GTest dependency
* added boost::program_options based frontent to InputXSLT
** example command: "./test --transformation ../dummy/transform.xsl --target out.xml"
** the plan is to use a simple shell script that generated test transformations and compares the output to reference files
|
|
* this was needed to share object files between the newly separated test-case and example target executables
* allows for easy development of multiple "frontends" to the same core functionality
|
|
* ... as a test of how well we are able to test DOM structures
* required change of constructDocument visibility
|
|
* XSLT stylesheets may be provided with a set of initial parameters
** these parameters can be provided as the second argument to the generate member method in the form of a string to string mapping
** the XSLT standard also permitts number and node set types as value arguments of such input parameters but this is not supported by this change
* expanded test transformation to demonstrate this feature
|
|
* contains a single, compiled transformation as specified by its construction argument
* uses the transformation's location as the FilesystemContext
* allows generation of output documents using _generate_ member method
|
|
* one expects a read-file function to work relative to the directory the transformation is located and not to the executable's location
** from the perspective of the user the transformation is the application, not the actual executable
* removed PlattformGuard struct from TransformerGuard (now TransformerFacade)
* TransformerFacade is instatiated with the appropriate relative working path
** i.e. it will have to be instantiated for every directory containing one or more transformations
|
|
* InputXSLT::PlattformGuard handles xerces and xalan construction and lifetime
* InputXSLT::TransformerGuard instantiates PlattformGuard, configurates external functions
** offers execute method for "executing" a XSL tranformation with empty input
|
|
* .. in the face of the planned development of usable external functions using the current proof-of-concept coding
* replaced usage of std::shared_ptr in FunctionReadXmlFile class with explicit implementation of default and copy constructor
* separated implementation and interfaces
|
|
* marked assignment and equality operators as deleted instead of making them private
* XercesParserLiaison is stored in a std::shared_ptr specialization instance for scope guarding
* moved implementation details into InputXSLT namespace
|
|
* command "read-xml-file" reads a XML file and allows it to be transformed by the calling XSLT
* this will allow workflows like the following:
** a tranformation reads all the markdown files in a directory
** these markdown files are converted to a xml representation by a external function calling a appropriate C++ markdown parser
** the XML representation of each markdown file is converted to XHTML inside the XSL transformation
** ... and embedded into the output XHTML document
** => all inside a single XSL tranformation
*** i.e. it is provided with only a empty dummy XML input file and fetches the actual input by itself
* as all current code contained within this repository this is just a quick and dirty proof-of-concept and not in any way good code
|
|
* changed relative paths of input files to accomodate builds inside a separate directory
|
|
* We don't want to pollute the main namespace with xalan classes while removing the version information inside the namespace
|
|
* quick and dirty proof-of-concept for adding plain-file access to XSLT
** based on Apache Xalan XSLT processor
* The idea is to create something like a static counterpart to Symphony CMS
* Adding functions to XSLT for file system, plain file and binary file (read)-access
* This project aims to test how such functionality can be integrated into XSLT
** if it works it could be developed into a nice static content transformation system
* Contrary to the popular opinion I actually like XML and XSLT when used responsibly
|
