Sounds good. As long as items that have no {thing} in them can still work,
sounds great.
I only used non-regex when I was tired of trying to work out how to escape
things that have to be escaped etc etc... (multiple escaping of some
characters was doing my head in). Feel free to tweak anything, the test
coverage should be pretty good. There are probably simpler ways of doing
some things.
I am also now thinking of allowing new lines in the mapping (the bit that it
maps to). I would strip those newlines out when applying it to the rule
though.
Also, I need to work out how to make the expression matching more space
tolerant - as they can get messed up sometimes.
Eg:
The {rain} in {spain}, falls mainly in {foo}
Will not work, as a space will appear before the "," and thus it won't
match. Ideally what I want is for spaces to be ignored, except when they
appear in string literals.
On 4/12/06, Edson Tirelli <[EMAIL PROTECTED]> wrote:
>
> Michael,
>
> I started to work on this issue and have a couple questions for you:
>
> 1. What I'm doing is creating the following method in NLGrammar:
>
> /**
> * Validades the mapping returning a list of errors found
> * or an empty list in case of no errors
> *
> * @return a List of MappingError's found or an empty list in case no
> one was found
> */
> public List validateMapping(NLMappingItem item);
>
> This method will internally call several private validation methods
> for the validations we want to do and return a consolidated list of all
> errors found. The errors, right now are instances of a new class I created:
>
> public class MappingError extends DroolsError
>
> * Is that approach ok?
> * Besides having a String error message, should this MappingError class
> store an error code? or even an error level (warning, error, etc)?
>
> 2. I saw that in some parts of code you make use of regex and in the
> others you don't. I guess this method will be called in DSL compilation time
> (optionally) and by IDE (on demand) to validate mappings. Do you see any
> problem in using regex to make the validations?
>
> 3. Right now I'm validating unmatched "{", illegal "token" names, unused
> tokens declared on the expression and tokens used in the mapping but not
> found in the expression. Anything else?
>
> Obs: I'm considering legal tokens those that follow this pattern:
> "\\{(\\w*)\\}"
>
> 4. Any other recomendation before I commit the code?
>
> Thanks,
> Edson
>
>
