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