[rules-users] Alternative for using a regular expression

[Wolfgang Laun]

Another alternative (in addition to what Michael wrote) would be the
implementation of a new parameterized operator. Assuming that you
need (String) equals and not equals for a limited number of substrings,
known beforehand, this isn't too difficult to implement (and I can provide
an example).

This means that you could write, e.g., for the "code" in (4:7)

  Claim( status eq[code] 1324,... )

or, for another substring

  Claim( status not eq[priority] "A",... )

You could also define indivdual operators (codeEq, priorityEq,...) but this
seems excessive.

Maintenance is not as bad as it might appear; the class implementing
the operator can access properties defining the parameter names,
offsets and lengths; so it is easy to adjust for future development.

As Michael wrote, all of this can be layered by a Domain Specific
Language, but that's not the key issue here.

-W



2010/10/20 Dean Whisnant <dean at basys.com>:
> Hello,
>
>
>
> In designing our rules system to allow users and analysts to create and edit
> rules (through Guvnor) we have a requirement that some of the fields be able
> to be evaluated for specific characters in specific positions of the
> string.  See the following examples:
>
>
>
> Example 1: The string named “claimStatus” contains various flags all pushed
> together in a string.  It might look like “ABS1324BB7”.  Together this field
> means about nothing, but position 4-7 (1324) is an important code that they
> want to evaluate. A business rule for this would be if position 4-7 in
> claimStatus = “1324” then we categorize that claims for some reason.
>
>
>
> In loose java syntax I would likely use ‘if claimStatus.substring(3,4) =
> “1324” then do something.
>
>
>
> I could have the user program a formula using the substring method, but that
> would be quite inefficient and a lot of information for them to figure out.
>
>
>
> I could have the user say claimStatus matches ^.{4}1324.{0,} but this
> regular expression is quite cryptic.
>
>
>
> While at Rulesfest I ran the topic by a couple folks there and they thought
> that posing it to the community might be a good idea.  Is there another way
> you could see doing this?  Is there a DSL format that might get us to where
> we want?
>
>
>
> Ideas that have been thought of included creating a variable that is already
> just the 4 characters we are after, but there are dozens of fields that
> could hold this info and that would increase our data model which is already
> quite verbose.  We also looked at allowing them to create a variable when
> they need it and then just reuse that in rules, but I’m not certain how we
> would do this with as many fields.
>
>
>
> To add to it, the regular expression I listed is for one of the fields in
> these streams, we also have needs to pull out other positions as well.
>
>
>
> Your thoughts and ideas on this are appreciated.
>
>
>
> Thank you!
>
>
>
> Dean Whisnant
>
> basys, inc.
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>