| Age | Commit message (Collapse) | Author |
|---|
|
* Wrapped xerces DOM and support class instances in now DomDocumentGuard scope-guard class
* FunctionReadDirectory class contains interal std::stack instance to store DomDocumentGuard instances
** wrapped in std::shared_ptr as FunctionReadDirectory is internally cloned by xalan...
** this is needed as the DOM has to preserved longer than the external function execution scope
* Sadly XMLCh xerces strings have to be manually released
** added appropriate xercesc::XMLString::release calls
* xalan::XercesDOMWrapperParsedSource does not mirror a given xerces DOM but convert it on instantiation
** this is why there is a dedicated finalize member method in InputXSLT::DomDocumentGuard
* In short: I do not like the amount of trickery needed to simply prevent memory leaks in this context
** there sadly doesn't seem to be a substantially easier way to return arbitrary DOM trees from a external function
|
|
* replacement for manual XML construction
* currently leaks memory as the objects have to exist out of scope and I have not yet thought of how to best manage their lifetime
|
|
* output is generated from XML hand-generated in a std::stringstream
** while this works reasonably well it is not how it should by done, i.e. this will have to be reimplemented using xerces / xalan constructs
** => this is intended to try out how a read-directory could work in a XSLT context
|
|
* _read-directory_ lists all files in a given directory
** currently text-only output, xml planned
* improved FilesystemContext path resolution (relative path is fully resolved by boost::filesystem)
|
|
* this class provides methods for resolving paths relative to the contained base path
* other filesystem interaction methods will also be implemented in this class
** for instance directory traversal
|
|
* while plain read access on files is doesn't require boost::filesystem it will greatly simplify the implementation of external directory traversal functions
* it also improves the portability of relative path construction
|
|
* there is no reason for performing system-calls instead of using the features offered by the standard library in this situation
|
|
* 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
|
|
* 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
|
