Navigation

RSS 2.0 New Entries Syndication Feed Atom 0.3 New Entries Syndication Feed

Show blog menu v

 

General

Use it

Documentation

Support

Sibling projects

RIFE powered

Valid XHTML 1.0 Transitional

Valid CSS!

Blogs : Archives

avatar
< Error-less error handling : Apple Developer Connection   At last, an excellent reason to ditch MySQL >
MVEL support in RIFE templates

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?

posted by Geert Bevin in RIFE on Dec 29, 2006 1:48 PM : 9 comments [permalink]
 

Comments

Re: MVEL support in RIFE templates
Congrats on the integration. Sounds like a good fit to the problem, but I'm not sure if I'd integrate it. One of RIFE's biggest selling points is the logicless templates. I think if you start offering little bits of logic, no matter how small, users will keep using their same bad habits.

It seems that requiring some kind of conscious effort on the part of the user to say "I want some logic in my templates" forces users to make well-reasoned / hopefully better decisions. Then again, maybe it'll help adoption.

Cheers,
Tyler
Re: MVEL support in RIFE templates
We started JFDI for the drools project, we are now investigating MVEL and are looking to move the JFDI efforts into MVEL.
Re: MVEL support in RIFE templates
Hi Mark,

that sounds interesting, JFDI still seems in a very early state so it really makes sense to adopt the bulk of the work that has been done by MVEL and enhance it with what you need.

Regards,

Geert
Re: MVEL support in RIFE templates
I've just tried the following expr:
misc.toList(foo.bar.name, 'hello', 42, {'key1' => 'value1', c => [ foo.bar.age, 'car', 42 ]}, [42, {c => 'value1'}] )

For 1mill iterations JFDI is about 60 times faster. Hoping to get hold of mike as either I'm doing something very wrong with MVEL or to see whether we can can get that level of perf with MVEL. The differences between the two codes is we do determine EVERYTHING at AST compile time, so there is nothing to determine or lookup at execution time. MVEL still does lots of repeated reducing, determining, reflection and lookups - even with it's compiled mode.
Re: MVEL support in RIFE templates
I'm sure that with your combined efforts, the resulting expression library will be the fastest out there :-)
Re: MVEL support in RIFE templates
Mark, to be fair... it's not really a fair comparison given the architecture and typical use cases. MVEL is clearly faster than OGNL for example... by a long shot... so it's not like switching from OGNL to MVEL is a step backwards.

That being said... the new MVEL 1.2 experimental build on Codehaus now has a fully working compiler and interpreter, that's only about 4 times slower than JFDI for the said usecase.

And let's not forget, that basically makes MVEL a bazillion times faster than OGNL.

Re: MVEL support in RIFE templates
We should also note that JFDI would not really be very easily integratable into the use cases seen in frameworks like Rife, or Struts... as they lately bind with the expectation of typeless property access in their view templates.

That being said, MVEL is replacing JDFI... and it will be faster soon. :)

Re: MVEL support in RIFE templates
MVEL 1.1.2 is now out. Compilation should be fully working and faster. Thanks to lots of help from the friendly JBoss Rules people for motivating me more than ever.
Re: MVEL support in RIFE templates
Hi, any body can help me on this?

In the example MVEL.eval("foo ~= (\\\\d+)(\\\\w+)'", vars),
how can I get matching groups like group(1) and group(2) as in java?


D.

Add a new comment

:) ;)
=) :-)
:'( :(
:/ :D
:| :p
:o 8)
Your email address will not be displayed at anytime on any page.
Only provide your email address if you'd like updates on this entry
and it's comments by email.
Please answer this simple math question:
17 + 14 = 
 
 
  

Manage subscription

Remove email:
 

< Error-less error handling : Apple Developer Connection   At last, an excellent reason to ditch MySQL >
 
 
 
Google
rifers.org web