Re: [rules-users] Contains substring in the LHS with regular expression capturing groups?

I really don't know about perf differences in this case. I guess best 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 significant difference. Regarding pluggable operators, here you have one example: http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-core/src/main/... 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 keep 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. []s Edson 2007/12/14, Waruzjan Shahbazian <wshahbazian(a)xiam.nl&gt;: > Hi, > > 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 > directly. > > 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 > > Thanks, > > Waruzjan > > Edson Tirelli schreef: > >> Yes, you may use matches. The other alternative is using an eval and >> > a > >> regular indexOf() call to check for the existance of the substring. >> > Drools > >> 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 >> > into > >> 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, >> > even > >> better. :) >> >> It is not possible to capture groups and reuse in the RHS. I'm >> > thinking > >> 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. >> >> Edson >> >> 2007/12/14, Waruzjan Shahbazian <wshahbazian(a)xiam.nl&gt;: >> >> >>> Hi, >>> >>> 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 >>> > expressions > >>> capturing groups and than use the results of the groups in the RHS? If >>> not, what is the best methode to do that? >>> >>> Thanks, >>> >>> Waruzjan >>> _______________________________________________ >>> rules-users mailing list >>> rules-users(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >>> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > > > ------------------------------------------------------------------------ _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users