Hi Edson,
just spend some hours compiling the most recent drools version from svn
trunk and migrating my application to this version. So far, most of the
features work except
- of one issue with BaseIntClassFieldReader, see JIRA ticket 1766.
- and an incorrect import in SendIcal.java leading to a broken maven
build proces, see JIRA ticket 1767.
Edson Tirelli wrote:
It has an interface you can implement to add operators and the
parser
accepts a quote for custom operators. It is not yet the way I want it to
be for Drools 5 final, but it works already.
For more info, look at the EvaluatorDefinition interface in Drools 5
and its several implementations for examples.
Having looked at the EvaluatorDefinition the implementation of custom
operators seem to be straightforward now. Nice Work!
1) One question though: In drools-core each subclass of BaseEvaluator
calls the parent class as follows
public MyEvaluator()
super(ValueType.SOME_TYPE, Operator.MY_OPERATOR);
with the operators created using the private (!) constructor
Operator(id, negated) via some static variable in Operator.java.
So, well, how do I hook up a custom operator to e. g. a drools package?
There is a PackageBuilderConfiguration.addEvaluatorDefinition() method,
yet currently the only way to define the operator symbol ("==" etc) is
via a separate call to Operator.addOperatorToRegistry() first and using
the return Operator instance to create my EvaluatorDefinition. Or do I
get something wrong?
2) Also, I am wondering about the large number of nearly identical
internal classes required for each operator.Is there a specific reason
why such an operator has to be defined for each possible object type
separately?
Is this due to the way the InternalReadAccessor is called to map to the
current datatype in an operator call? And why not just call
cu, Michael
PS: Some details about my project come once I find a bit of time to
write them down coherently :-)