Age | Commit message (Collapse) | Author |
|
* "xsl:output" was disregarded for xalan::FormatterToXML based output
** the setting contained within this tag have to be passed manually to the constructor...
** the xalan standard implementation includes special handling for this case
** sadly there was no alternative to adding special handling in InputXSLT as well, it is really quite ugly
* added "dispatchTransformer" template member method to TransformerFacade
** calls xalan::FormatterToXML augmentation logic if needed, compiles template
* this problem also exists for FunctionTransform output to xercesc DOM
** this patch doesn't aim to fix it in that case, it will have to be fixed separately
|
|
* pointers to xercesc::DOMDocument were manually released
** this is now solved using a custom deleter for the appropriate std::unqiue_ptr template specialization
* added matching factory method to DomDocumentCache
* updated external function implementations accordingly
** "constructDocument" is now expected to return a DomDocumentCache::document_ptr instance
* updated TransformerFacade accordingly
* this change was implemented to get rid of the manual memory management required by xalan / xerces
|
|
* 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
|
|
* 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
|
|
* 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
|
|
* 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
|