António: I wouldn’t implement the “=” myself

The “=” was a type, should been “>=” Ah, thanks for the notice, added a list of allowed tags/elements under the comment-area now – and edited your comment.

António: But I think I’m missing something here, can you please comment to my e-mail?

Yeah, I’ll send you an email so we can discuss it further with more ease.

I added some operators, but my operators were only useful when we allow other values then true/false, so a quick hack which made it work for me was to replace:

“return !!markuper.getData( data, key )” in markuper.evaluator.getBooleanValue, with:

return (markuper.getData( data, key )) ? !!markuper.getData( data, key ) : key;
uhm… then it stopped being a getBooleanValue right?

The problem here is that it’s now three kinds of data to use in the attribute-values:

1. {{var}}, which will be replaced to it’s corresponding value – then treated as 2 or 3.
2. “var” which if matches a key in the dataset will be set to true/false
3. “var” which if not matches a key will be used as-is

So my thougts right now is that you should be consistent in using the {{var}}-format when dealing with variables, which in turn could be true or false to allow for easy checks – and otherwise treat the values as actual data.

I’m not really sure what you mean with “you should be consistent in using the {{var}}-format when dealing with variables”…
The 1. and 3. point only happens because you changed the code right?
But I think I’m missing something here, can you please comment to my e-mail? it would be much easier for me to follow up and reply

This worked well when I implemented some operators through evaluator.operators, like “>”, “<", "==", "=”, “!=” etc. What do you think?

I wouldn’t implement the “=” myself but the other ones I was going to of course, just didn’t have the time at the time (yeah yeah, I know it’s just a few lines of code but I also create unit tests and more documentation, etc.)

I added some operators, but my operators are only useful when we allow other values then true/false, so a quick hack which made it work for me was to replace:

“return !!markuper.getData( data, key )” in markuper.evaluator.getBooleanValue, with:

return (markuper.getData( data, key )) ? !!markuper.getData( data, key ) : key;

- which then the method first will look for booleans, otherwise just return the key itself, which now only will be the value to compare. The problem here is that it’s now three kinds of data to use in the attribute-values:

1. {{var}}, which will be replaced to it’s corresponding value – then treated as 2 or 3.
2. “var” which if matches a key in the dataset will be set to true/false
3. “var” which if not matches a key will be used as-is

So my thougts right now is that you should be consistent in using the {{var}}-format when dealing with variables, which in turn could be true or false to allow for easy checks – and otherwise treat the values as actual data.

This worked well when I implemented some operators through evaluator.operators, like “>”, “< ", "==", ">=”, “!=” etc. What do you think?

What do you think?

It seems that you’re already looking at the latest version, I thought you were using the one documented at dev.opera.com.
Isn’t the markuper.evaluator.operators array enough for you to add new operators? I wanted to have a very simple and easy-to-grasp expressions support but I can change it depending on developers feedback, so any feedback on this subject is most welcome
I can’t say when the next release is coming out, the one with strings and numbers support, and some other goodies. But I’ll (most likely) only be working on it after the final release.

That sounds great, I’m looking forward to the next release. Do you have any estimates regarding when this will be? As I’d like to know if it’s worth it’s time developing my own version, or just stick with my simple method, which will do during development.

Regarding the “operatorsRegExp”, it’s quite different now (haven’t released yet because I need to finish the documentation), and it will support more operations/numbers/strings in the next release.
The library is still under construction, we are adding new features as we need it.