Age | Commit message (Collapse) | Author |
|
i.e. the directory tree was not correctly created in all circumstances which led to both the `generate` and `write-file` test cases failing. This was combined with some accumulated changes such as the extraction of process context instantiation.
|
|
* changed the XObjectValue constructor to accept a pointer to FilesystemContext instead of instantiating the context by itself
* the FilesystemContext is now instantiated in the "callConstructDocument" member method of "FunctionBase"
** a const reference to FilesystemContext is passed to all "constructDocument" member method implementations
* the FilesystemContext is currently only used by FunctionExternal command to set the correct work directory in "boost::process::context"
** this is required so calling external commands from inside a stylesheet works as expected
*** i.e. from inside the directory the stylesheet is located in
* modified all remaining external function implementations accordingly
|
|
* they don't modifiy the class state so there is no reason for them not being marked as const
** all calling methods are also const
** this enables us to remove the const_cast in FunctionBase
* modified external function implementations accordingly
* inlined handleError method in FunctionTransform as it is not needed in multiple places anymore
|
|
* previous createDocument method used default name "content"
** this led to problems when using xalan::XalanNode as transformation input
** the parameter-less createDocument overload now creates a unnamed xercesc::DOMDocument
* changed external function implementations accordingly
|
|
* the common use case of ResultNodeFacade inside external function implementations is managing the result root node
** this root node can be fetched through the xercesc::DOMDocument instance
** the new alias overload automatically fetches the root node pointer and as such doesn't require a root node parameter
* changed external function implementations accordingly
|
|
* 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
|
|
* using xalan::FormatterToXercesDOM internally
** this required changes to the TransformationFacade::generate member method overloads
* TransformationFacade::generate now accepts references to xalan::FormatterListener instances
** "generate(std::basic_ostream<char>&..." instantiates a xalan::FormatterToXML and passes it to the actual generate member method
* changed ResultNodeFacade's "getNode" method into a "getResultElement" method
** xalan::FormatterToXercesDOM requires a xercesc::DOMElement instance instead of the previously available xercesc::DOMNode instance
** changed FunctionReadDirectory accordingly
* adapted FunctionTransform test case accordingly
|
|
* added support for defining boost::filesystem::path as a external function parameter
** boost::filesystem::path parameters are resolved against the appropriate FilesystemContext and IncludeEntityResolver instances
* xalan::XSLTInputSource parameter source paths are also resolved
* removed need for passing a reference FilesystemContext to "constructDocument" methods
** they now only accept the parameters of the external function implemented by them
** all path resolution logic is wrapped by the newly created XObjectValue class
* converted XObjectValue namespace into class
** the "get" template method is now a template member method
** this was needed to enable value casting logic to access the appropriate FilesystemContext and IncludeEntityResolver instances
* this commit marks the next step towards the goals defined in 741a70f
|
|
* replaced std::tuple constructing Mapper template methods with direct XObjectArgVectorType unpacking
** XObjectValue::get template method is applied directly using parameter pack unpacking
* implemented custom IndexSequence / Sequence type to provide vector indexes
* modified all external functions to provide matching constructDocument overloads
|
|
* the root node of the result tree of each function is a domain element
** i.e. the root node of "read-xml-file" is "file", the root node of "read-directory" is "directory"
* the root node contains the result state of the function call encoded in a "result" attribute
** possible values are "success" and "error"
** the root node may contain additional attributes such as the target path of a called transformation
* the actual function result is contained within the child nodes of the function root node
** i.e. the XML file tree returned by "read-xml-file" is a child of the function root node
** if specific errors occured they are also returned as child nodes of the function root node
*** this is currently only the case for "transform" where transformation errors are returned as "error" value node childs of the function root node
* updated test cases accordingly
|
|
* there are situations where one may pass absolute paths to external functions which should not be resolved against the context path
** for example when reading files found by "read-directory" through its "full" value node
* this could be checked by the external functions themself
** but as this check is required by all of them it is better implemented in the FilesystemContext
|
|
* wraps result node construction and appends it to root node on destruction
* offers a simpler interface for common node construction patterns
* simplifies result node construction in all external function implementations
** most noticeable in FunctionReadDirectory
* expanded FunctionReadDirectory result nodes by name, extension, and full-path nodes
|
|
* names matter, from now on parameters to external functions will be called parameters uniformly instead of mixing arguments and parameters
|
|
* FunctionBase::argument_tuple is a std::tuple specialization type specialized on the argument types passed inside the variadic template argument of FunctionBase
* added tuple Mapper and XObjectValue helper namespaces containing recursive tuple construction and XObjectPtr value extraction logic
* changed all external function implementations accordingly
* this change was implemented to uniformly support different external function argument types than std::string
|
|
* external functions may expect arguments with a type different from boost::filesystem::path so they are only provided raw string values
* moved xalan string conversion logic into separate compilation unit
|
|
* constructDocument member method is provided with a FunctionBase::argument_array instance
* improved argument validation in FunctionBase
* this parameter was added to support FunctionBase as a base class for FunctionTransform
|
|
* 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
|
|
* 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 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)
|