olabusayoT commented on a change in pull request #273: WIP: Add User Defined
Functions Capability
URL: https://github.com/apache/incubator-daffodil/pull/273#discussion_r331535540
##########
File path:
daffodil-test/src/test/java/org/goodudfs/example/StringFunctions/StringFunctionsProvider.java
##########
@@ -0,0 +1,25 @@
+package org.goodudfs.example.StringFunctions;
+
+import org.apache.daffodil.udf.*;
+
+public class StringFunctionsProvider extends UDFunctionProvider {
+ public StringFunctionsProvider() {
+ super.setFunctionClasses( new Class<?>[] { Replace.class,
Compare.class } );
+ }
+
+ public Object lookupFunctionClass(String namespace, String name) {
+ Object functionClass = null;
+
+ String nn = String.join("_", namespace, name);
+
+ switch (nn) {
+ case "com.ext.UDFunction.StringFunctions_replace":
Review comment:
@mbeckerle The namespace string doesn't match to demonstrate that it
doesn't need to match the java namespace.The thought process was to give the
user the ability to provide a namespace like "http://ext.stringfunctions.com";
in the xsd, when the namespace of the udf was something like
org.apache.daffodil.udfunctions.javafunctions.Stringfunctions for example. If
we don't want to provide this functionality, the lookup is the same for us,
we'll call lookupFunctionClass with whatever namespace/name is provided in the
schema. It'd be up to the provider to implement the lookup how they wish.
@stevedlawrence So the advantage of having lookupFunctionClass is that it
provides a object, which means it can also provide state to the object it
initializes. Whereas if we are responsible for initializing the class, we would
also be responsible for initializing it with whatever state it might need.
Initializing objects can also be a bit messy from reflection, so I thought it
best to leave that in the hands of the provider class. It might need a name
change as it's literrally supposed to be returning an object, not just a class,
like getFunctionClasses would.
I'm not against the static namespace/name methods, and if we choose to
provide a UDF abstract class that they have to extend, we can sort of force
them to have it, but the checks we'll have to do to make sure it actually
returns valid values are not so different for what we do for annotations. So
I'm not sure which is better either.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
