The pluggable operators example looks very cool :-) , I just have one
more question about the performance. I suppose that if I use eval() with
indexOf(), there would be no caching? Isn't that one of the benefits of
using the "drools" operators, since ( if they work on the same way as in
the example in the trunk anyway) they do use caching. Anyway, if I do
some benchmarks about this I would let you now!
About the backwards compatibility: Thats cool, as long as what I did was
not a not recommended way. The costes for the few possible changes in
the feature are indeed affordable to pay.
Edson Tirelli schreef:
I really don't know about perf differences in this case. I
thing would be for you do give a try (and let us know please). :) It
probably will depend on the java implementation of the matches() against
indexOf() method. I guess indexOf is faster, but don't know if it is
Regarding pluggable operators, here you have one example:
Regarding using the descriptor classes, I would say it is the
recommended way for generated rules, since you avoid the "text
generation"+"parsing" cost of the rules. Although, as much as we try to
backward compatibility, we can't guarantee there will be no breaks, since we
are always adding new features and the descriptor model must usually change
to support them what may eventually break backward compatibility. Even with
that, I think it is an affordable cost to pay (fixing eventual breaks on
version updates) compared to your runtime application robustness.
2007/12/14, Waruzjan Shahbazian <wshahbazian(a)xiam.nl>:
> Thanks for the reply. I wanted to be sure that there wasn't any more
> efficient way to check a substring in a string, or do you think that
> eval() with a indexOf() call would be more efficient than matches() with
> regular expression?. Since I can't group the results, the speed is the
> only issue here.
> In my application I am creating the PackageDescr myself with some
> "template" RuleDescr's (which are being filled in with the, limited,
> user input in the Swing GUI) and the package is being build with the
> builder. If the regular expression methode in the matches operator is
> the best way to check a substring in a string, I can use variabeles
> (which are the user inputs) to fill the regular expression. So I don't
> really need a new operator for this. But I am interessted how the
> development of a new operator would be, so maybe you could tell me where
> I need to be to do so :-) .
> In the attachment is the classe diagram of the PackageDescr with the
> linked classes as I have understood and used in my application. Of
> course not every operation and attribute is included, but maybe this
> could be helpfull for someone else who wants to create PackageDescr's
> I suppose the public methodes used in this operation are going to be
> supported by the following drools versions? Or should I have used the
> DRL and XML ? =-O
> Edson Tirelli schreef:
>> Yes, you may use matches. The other alternative is using an eval and
>> regular indexOf() call to check for the existance of the substring.
>> up to versions 4.0.x is JSE 1.4 compliant, so you can't use contains()
>> method. In trunk, you may also develop your own operator and plug it
>> the engine... although, it is not documented yet, but if you want to
> try, I
>> can guide you through. And if you want to contribute docs after that,
>> better. :)
>> It is not possible to capture groups and reuse in the RHS. I'm
>> about a way to bind variables to arbitrary values in the LHS. If we
>> implement that, than it would be possible for you to do that, but not
>> possible at this moment.
>> 2007/12/14, Waruzjan Shahbazian <wshahbazian(a)xiam.nl>:
>>> I need to check in the LHS of my rule if a given String contains an
>>> given substring. What is the best way to do that? I can use regular
>>> expression with matches, but is that the best (fastest) solution?
>>> (STRING matches "(?i).*SUBSTRING.*"). And can I use regulare
>>> capturing groups and than use the results of the groups in the RHS? If
>>> not, what is the best methode to do that?
>>> rules-users mailing list
>> rules-users mailing list
> rules-users mailing list
rules-users mailing list