* if the target parameter is not provided FunctionGenerate now performs exactly the same functionality as FunctionTransform * added "boost::optional<boost::filesystem::path>" specialization to the XObjectValue class * modified test cases accordingly * modified README.md accordingly
* this change was implemented to match the naming scheme of all other external functions * updated external text formatter test case accordingly
* renamed FunctionExternalTextFormatter into FunctionExternalCommand ** the goal is to provide a general interface to a variety of external commands *** e.g. not just text formatters but system utilities for file management and so on ** this requires the stdin parameter to be optional as not all external commands require stdin input * implemented "filter_derived" helper template to determine amount of optional parameters ** optional parameters are defined as "boost::optional" specializations *** they in turn can be detected by checking if "boost::optional_detail::optional_tag" is a base class * "callConstructDocument" member method of "FunctionBase" performs additional bounds checking of parameter vector * "boost::optional<std::string>" specific member overload was added to "XObjectValue" helper class ** we will have to provide full specializations for all optional types as C++ prohibits partial member function template specialization * renamed the external function in "PlattformGuard" * changed README.md and test cases accordingly
* otherwise one has to pass the full path to the command ** additionally it is much easier to enable passing arguments to the external formatter this way * modified external function parameter accordingly * updated external text formatter test case
* this function essentially provides the same functionality as FunctionTransform with the addition of directly committing the result to the filesystem ** this is needed if one wants to generate doctype-containing transformations from inside a transformation as "write-file" is not able to infer the doctype of a given xalan::XalanNode pointer ** this is a integral limitation of (at least) XSLT 1.0 as implemented in Apache Xalan *** a document can of course only have a single document type *** e.g. we can not include a doctype node in the result tree of FunctionTransform * implemented test case for FunctionGenerate * transformation "test.xsl" is shared between the FunctionTransform and FunctionGenerate test cases * modified README.md accordingly
* as FunctionTransform returns the result as a DOM tree there is no reason for including the separately tested FunctionWriteFile in this test case
* 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
* 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
* neither the constructor nor the generate member methods need to be templatized ** only supported "output" argument is now a reference to a "std::basic_ostream<char>" instance ** the caller is responsible for e.g. writing the output to disk * this was done to simplify the basic interface of InputXSLT * removed "default_params" testcase along with default parameter generation ** this feature is neither used nor required
* test cases should also provide examples of how the tested external functions may be integrated into transformations ** helper templates such as "formatter" or "transformer" are an important step into this direction ** especially functions other than plain read-only functions fit much better into a template context than a XPath context
* i.e. "write-file" now supports the serialization of given DOM structures ** this will be needed e.g. if FunctionTransform returns the result as a DOM tree instead of as a plain string ** enables the creation of multiple XML documents from within a single transformation *** i.e. backports the functionality provided in XSLT 2.0 by "xsl:result-document" to xalan's XSLT 1.0 * changed test cases accordingly
* the external "transform" function now expects a input document as its first parameter ** this input parameter is resolved and passed as input to the transformation ** changed and expanded test case accordingly * because of xalan internal problem this currently only supports input DOMs loaded directly from the fs ** passing result trees or node sets analog to how the transformation may be passed into the function leads to parsing and assert failures ** parsing node-based input DOMs using xalanc::XalanTransformer::parseSource produces errors concerning base entity resolution ** if the error capacitor instance is temporarily disabled it works correctly as long as one doesn't try to access the input document *** this causes a assert failure in the XPath implementation (seems to be related to XALANC-540)
* slightly improved FunctionTransform test case utility templates
* accepts a path parameter and the content to be written * removed target parameter form FunctionTransform ** transformation result is now returned as a string *** nodeset return value is planned ** e.g. writing the result to the fs is optional and has to be achieved using FunctionWriteFile * changed "transform" test case accordingly * this marks a paradigm shift and is the continuation of the changes described in 741a70f ** InputXSLT now also implements a output function * added basic io error handling to FunctionReadFile
* previous logic for resolving boost::filesystem::path parameters in the XObjectValue class actively tried to resolve existing files ** this contradicts the planned introduction of e.g. a external "write-file" function * callers of external functions with path arguments now have to enclose them in square brackets if include path resolution is required ** analog to the usage of the "xsl:import" tag * moved "getPathFromSystemId" from compilation local method into static method of IncludeEntityResolver * changed test cases 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
* FunctionTransform was adapted to support passing the transformation as either a string path or directly as a node-set / result-tree ** this in turn required changes to the TransformationFacade ** the implementation of a xalan::XSLTInputSource specialization for the XObjectValue::get template method was also required * changed ixslt executable to match TransformationFacade constructor changes * these changes were implemented in preparation for a restructuring of how the separate external functions provided by InputXSLT operate and work together ** the approach up until now was to provide non-combinable external functions for distinct task such as "read a file" and "transform that transformation using these parameters into that file" ** if you think about the areas of operations of these functions are overlapping quite a bit *** e.g. FunctionTransform reads files, transforms DOM structures and writes files instead of only transforming things ** the new approach will be to limit the feature set of each function in the attempt of making the clearer and increasing their combinability *** e.g. FunctionTransform won't read or write files but expect both the input-DOM and the transformation-DOM as node-sets or result trees and return the transformed document as a node-set to be written using FunctionWriteFile (to be implemented)
* FunctionReadFile is now able to distinguish between XML files and plain text files ** it selects the appropriate course of action automatically ** reading the file as XML into the DOM or reading it as a string * the current selection criteria is the file extension ** I am thinking about trying to import every file into the DOM and using the result state of that action as selection criteria * Updated README.md and test cases accordingly
* improved "ixslt" frontend code structure ** extracted input, process and output logic into separate methods ** removed manual "--transformation" parameter check as it is defined as required
* variables containing the output of a external function can be defined using the "select" attribute ** tree-like definition is only needed when helper templates such as "transformer" are used ** queries on variables that are instantiated in this fashion need the "self::" prefix before base nodes * changed includes of the "testcase.xsl" base template to imports ** this signifies that the importing template is based on the imported template ** ... and this is exactly what we want to define
* 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
* ErrorHandler class created in 5859cb6 now caches all errors instead of pushing them to std::cerr ** cached errors are retrieved by TransformationFacade's "generate" member method * test frontend pushes all errors to std::cerr * FunctionTransform returns errors to the calling template as XML ** FunctionTransform test case demonstrates how one may test for successful transformation * "generate" member method returns std::string vector wrapped in a std::unique_ptr ** this is used as a kind of optional pointer, as the std::unique_ptr instance only wraps a vector if errors where actually generated
* InputXSLT::ErrorHandler is derived from xercesc::ErrorHandler and enables contextual printing of transformation errors ** currently this means that the error messages passed to std::cerr contain the full path of the offending transformation * added input trimming to the external transform function ** calls to this function from inside a transformation may contain unnecessary whitespace characters which disrupt further processing
* verifying type attribute and extension value node if available
* test case requires markdown.pl formatter to be available in "/usr/bin/" * updated README.md to mention "external-text-formatter" instead of "execute" * updated "read-directory" test case reference file * included library resolution test into "read-file" and "read-xml-file" test cases
* 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
* test case base template contains the basic test case markup ** it was mostly created to include include-path resolution into the test cases * improved transformer helper template by separating the external function call into its own variable
* added basic "transformer" wrapper template to call "InputXSLT:transform" ** this removes the need to specifiy arguments in a separate xslt variable
* the given XObject is passed to the called transformation ** this was done to enable templates to pass information to each other ** this should support any type usable in a XPath context to be passed as an argument * expanded FunctionTransform test case accordingly
* order of items in a directory was varying across platforms which hindered testability * they are now temporarily copied into a std::vector instance and then sorted using std::sort * updated "read_directory" test case reference file accordingly
* "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
* 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
* 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