Extension Elements and Functions

[ballsteve]

Discussed in #114

^{Originally posted by zackpcodes October 12, 2024}
Hi all! My team and I are planning to modernize our tech stack and re-write our main back end API in Rust. One of the key features throughout our system is XSL transformation. One key functionality we utilize is extension functions with our current library. I browsed the xrust code base, correct me if I am wrong please, but it seems there is no way to register custom functions. Is this something y'all would be interested in taking pull requests on? If so, any ideas of how you would like this implemented?

Best

[ballsteve]

Created branch extensions for this development.

[zackpcodes]

Hey Steve,

I messed with this a little today and was able to get custom XPath functions to to work. I missed your message on the discussion and created a pull request to "dev". Take a look and see if i am on the write track and I can get a pull request on the extensions branch.

#117

Best

[ballsteve]

Looking at the Transform enum, perhaps we can extend the Invoke variant and the Callable struct to handle custom/extension functions?

I'll have a crack at that and see how far it goes.

[zackpcodes]

Sounds good! I was kinda of thinking something similar I believe. Take a look at what I pushed to my fork a few hours ago on the extensions branch.

[ballsteve]

Do we want the application callback to be a function that takes arguments (a vector of Transform), or a closure? The StaticContext already has a few closures (messages, external resources, parsing), and that's a more Idiomatic Rust way of doing things. However, there would need to be a closure for each different extension, identified by QName, so I'd have to see how that works.

[ballsteve]

The thing about closures is they can't be cloned, that's why there's a separate StaticContext structure. Context needs to be clonable.

[zackpcodes]

Agreed. Based on what I read I think closure makes more sense than a function. I think carrying vars from the surrounding scope would be good. My team currently uses hash maps outside of the function scope to look up values and stuff which is functionality we need to retain.

[ballsteve]

I've checked in my (incomplete) code that adds extension functions as a closure to StaticContext and Callable. Have a look and let me know what you think. In the meantime, I'll keep working on it to get it compiling and with tests to show how it works.

[zackpcodes]

Looks great so far man! Look forward to trying it out

[ballsteve]

Today's push into the extensions branch adds an extension callback to StaticContext. Have a look in tests/transformgeneric at the generic_tr_callable_extension_1 test to see how it will be used.

The test is failing - it's not finding the extension. I'll have a look at that tomorrow. In the meantime, you might like to see if you can develop another test that uses the Context to read a variable. After fixing the failing test, the next thing I'll do setup the FormalParameters for the extension so that they work like an xsl:function.

[ballsteve]

It would have helped to actually pull the extension closure out of the static context :-(

Today's push in to the extensions branch has a working example of calling an extension function, i.e. a closure.

[ballsteve]

It turns out that the previous implementation didn't allow for multiple extensions to be defined. To fix that I've Boxed the callback closure and made it dynamic. Having multiple extension functions now works, and there's a test in transformgeneric/mod.rs that demonstrates this.