| Age | Commit message (Collapse) | Author |
|---|
|
* "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
|
|
* using std::unordered_map for named cache lookups was a nice idea but is not useful when one keeps in mind that:
** we don't want cached external function responses in a situation where we are able to execute transformations inside transformations
** cached responses mean that we can not read a xml file, overwrite it using another transformation and then read it again
* the currently available InputXSLT frontend only processes a single transformation anyway, so increased memory requirements should not pose a problem
** if a future frontend should offer batch processing of transformation tasks, one could implement a cache reset method to free memory after a transformation has been processed
|
|
* fixed compiler flag variable (previous content was deleted)
|
|
* removes responsibility for clearing parameters from the generate member methods
* abstracts parameter escaping and setting and handles map conversion
* marked actual generate member method as private and added StylesheetParameterGuard reference argument
** "frontend" generate member methods instantiate a StylesheetParameterGuard instance and pass it to the actual generate method
** this enables central default parameter definition while offering the possibility for custom parameters
|
|
* 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
|
|
* as the xerces document is not instantiated by DomDocumentCache::item and the class only exports a pointer to the converted xalan document, it makes no sense to expose the class to the outside in the first place
|
|
* the directories below "./test" contain test cases
** "transformation.xsl" and the expected result as "reference.xml"
** tests are performed by "check.sh"
*** returns diff on error
* this system enables simple verification of external function results
** way simpler than C++ unit tests would be in this scenario
* expanded cmake instructions to automatically execute the test cases
* old example transformation was removed
|
|
* 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
|
|
* common parts were moved into CRTP template base class _FunctionBase_
* all external functions are derived from that class
** only have to implement _constructDocument_ member method
** currently only supports a single string input parameter which is enough for now
* this change condenses external funtion implementations to the essential and should increase readability as well as maintainability
|
|
* this change makes the underlying similarity between all currently implemented external functions obvious
* they more or less only differ in their document construction logic
** i.e. there is a possibility for a second layer of abstraction between the classes derived from xalan::Function and the actual functionality
* added boost::filesystem::path taking overload of the _iterate_ member method to FilesystemGuard
** this overload functions as the _master_ overload that is called by all other overloads which merely perform type conversion and path resolution
** this overload doesn't perform path resolution
|
|
* all instantiations of a FilesystemContext are currently based on information provided by a xalan::Locator instance provided to the external function execute member method
* this change hides the stylesheet path extraction from the actual function implementation
|
|
* DomDocumentCache::item class now is _finalized_ by default and doesn't perform document instantiation, just lifetime management
** xercesc::DOMDocument is instantiated inside the external function implementations and committed to the document cache for conversion to a xalan document
* added mutex with scoped lock to prevent concurrent write access to the std::unordered_map contained withing DomDocumentCache
* functionality of the _get_ member method was split into _get_ and _create_
** added typedef for std::pair specialization type "optional_item" that functions as the return value of _create_ and _get_
* "locator->getSystemId()" was leaking memory as xerces doesn't manage the lifetime of the returned heap-allocated char array
** analog to XMLCh* strings
** transformed XercesStringGuard into template class to be instantiated on either XMLCh or char
|
|
* up until now all external functions were locally installed to a specific XalanTransformer instance contained within a TransformationGuard instance
** this had to change as I planned to add a "execute-transformation" function based on TransformationGuard which would have led to recursive self-instantiation
** global external functions have to be thread-safe
* as global external function can not be provided with a reference to a transformation-specific FilesystemFacade instance, the working path is now determined using xalan::Locator
** currently using pointer arithmetics on XMLCh* to remove the "file://" prefix of the URI returned by locator->getSystemId(), may be unsafe
* added compilation unit for PlattformGuard as it now contains function installation in addition to plattform lifetime management
|
|
* 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
|
|
* "InputXSLT" is defined as "function.inputxslt.application"
* functions can now be accessed like "InputXSLT:read-file('../')"
* updated test transformation accordingly
* the XML standard does not require namespaces to be real, valid HTTP-URIs but treats them as plain strings
|
|
* it was moved into functions local to the respective compilation unit to improve readability
** splits DOM tree construction logic from the actual purpose of the external function
|
|
* all functions return a single "error" node in the case that something went wrong
* otherwise they return one or more "result" nodes that contain the function results and may be distinguished by one or more attributes
* this makes handling the return values easier and more pleasing to the eye as not everything has to be prefixed by "self::*"
* updated test transformation accordingly
|
|
|
|
* throwing std::out_of_range exception from DomDocumentCache::get instead of returning nullptr in case of a problem
* moved xalanToString method back into FilesystemContext compilation unit as is only needed there
|
|
* XML tree is contained below the _content_ node if read was successful
** status is set to error otherwise
* updated test transformation accordingly
|
|
* updated test transformation accordingly
|
|
* A call to _read-file_ now returns a _content_ and _status_ node
** this enables XSL transformations to easily react to io related errors
* fixed bug in path resolution
** boost::filesystem _canonical_ method is throwing and exception when the given path does not exist, this pulled down the whole stack
** replaced call to _canonical_ with call to _absolute_ which does not have this requirement
|
|
* A global DomDocumentCache instance would require key prefixing
* switched internal data structure to std::unordered_map for average constant time access
|
|
* the plan to return XML-nodes from each external function requires a better way to manage the lifetime of many xerces DOM document instances and their support class instances
** this is why DomDocumentCache and DomDocumentCache::item were implemented
** based on std::map so we can easily access the result of old function calls
* changed external read-directory function to return the children of the document node instead of the document node itself
** removes unnecessary cruft in function calls
** will make returning status codes alongside the function result more pleasing to the eye
* updated test transformation to reflect new features
|
|
* execute member method internal argument count checks are not needed when using between one and two arguments
** xalan automatically generates the appropriate message containing the getError message when only offered fixed argument execute member overloads
* improved FunctionReadDirectory attribute element generation
* added additional validations to FunctionReadFile and FunctionReadXMLFile
* I plan to return errors inside a DOM tree alongside the function return values in the future
|
|
* xercesc requires XMLCh* strings to be hand-allocated and released using the XMLString class
* XercesStringGuard works as a scope-guard for XMLCh* string lifetime and greatly simplifies xerces DOM construction
|
|
* they are marked appropriately by a _type_ attribute
|
|
* 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
|
|
* 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
|
|
* 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
|
