aboutsummaryrefslogtreecommitdiff
path: root/src/transformer_facade.cc
AgeCommit message (Collapse)Author
2014-07-13Improved xalan::XalanCompiledStylesheet lifetime managementAdrian Kummerlaender
* added custom deleter for xalan::XalanCompiledStylesheet specific std::unique_ptr specialization * added previously missing check for successful stylesheet compilation
2014-07-10Fixed TransformerFacade doctype output for xalan::FormatterToXMLAdrian Kummerlaender
* "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
2014-07-07Implemented custom xercesc::DOMDocument deleterAdrian Kummerlaender
* 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
2014-07-05Revamped implementation to support FunctionTransform XalanNode inputAdrian Kummerlaender
* 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
2014-04-24Changed TransformerFacade into TransformationFacade for single XSLTsAdrian Kummerländer
* 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
2014-04-23Fixed xerces DOM construction related memory leaksAdrian Kummerländer
* 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
2014-04-22Implemented basic XML output of external read-directory functionAdrian Kummerländer
* 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
2014-04-21Implemented basic external directory traversal functionAdrian Kummerländer
* _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)
2014-04-21Extracted filesystem path resolution into InputXSLT::FilesystemContextAdrian Kummerländer
* 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
2014-04-20Implemented support for modifying external function base pathAdrian Kummerländer
* 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