A couple of years ago I planned writing a very small boolean expression language for usage in RIFE. None of the existing ones really felt like a good fit, but I ended up adopting OGNL, Groovy and Janino anyway due to lack of time. What bothered me most about these is that they are too powerful for their intended purpose and that users could potentially stuff too much logic inside templates.

Expression languages in RIFE are only used to conditionally assign the content of a template block to a value. This allows you to easily show certain parts of the interface depending on, for instance, the role of the user, an application-wide configuration parameter, another template value, etc. The only function of the expression language is to evaluate short conditions that result in true or false, thus meaning: should this block be assigned to the value or not.

Come MVEL, I saw it being mentioned on the Groovy IRC channel yesterday and had a look at it. It seems that the language supports exactly the feature set that I wanted to implement for our own expression language. MVEL can be very easily integrated and supposedly performs better than the rest. It is still lacking real-world testing by a large user community though and I stumbled into a series of minor issues with it. Chris Brock, the developer, is very responsive and seems extremely passionate about resolving problems as quickly as possible.

Today I committed MVEL support to the RIFE subversion trunk and will most likely be advocating it as the best choice for our blockvalue scripting feature as of RIFE 1.6.

I'm even wondering now if I should not integrate MVEL entirely inside the core RIFE distribution jar, as I've previously done with ASM and PCJ. This would mean that blockvalue scripting will be available to anyone without having to figure out which jar file they need for it.

Any thoughts on that?