BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Geert Bevin on The Philosophy Behind RIFE

Geert Bevin on The Philosophy Behind RIFE

Bookmarks
A few weeks back InfoQ covered the 1.5 release of the RIFE Java web framework. This week Artima Developer featured an extensive interview with RIFE founder Geert Bevin. In the interview Geert explains the history of RIFE. The questions then move on to how declarations help the framework:
A very simple example is your page URLs. One of the main problems in coding Web applications is how to put a URL into a form or a link: How do you insert that URL there so that if you reuse that application, the URL remains consistent? For us, that was very important because we work on multi-language sites, and we have customers who ask for specific localized URLs. We have to be able to change a URL into a French URL, but keep the same functionality. For that to work, you should be able to specify a URL in one place, and the framework should ensure the consistency of that URL in the view. RIFE allows you to do that...

They also talk about new features in 1.5:

...That's also an example that declarations don't have to be specified in an XML file. A lot of people today are allergic to XML. Every declaration and configuration in RIFE can be specified in plain Java. It's not just a matter of setters and getters, leaving you with having to invoke many calls on the same object instance. Instead, we actually wrote out fluent interfaces that allow you to chain those calls. It looks very similar to a nested structure you would have in XML, except that it's in Java...

Towards the end of the interview Geert provides a good example of using continuations in RIFE:

People have also been using continuations for event-based systems. Suppose you have an events flow declaration that takes several steps chained together. When a certain event happens, an application has to perform an action.

What you'd typically do is poll for state: You would have some kind of sleep time, and then poll to see what the state is, and if the state is not what you want, you just wait a little while, and when the required state is detected, you take the correct step.

Continuations turn that problem around. If you're at a step that requires additional information to continue, you can capture a continuation and stop the execution completely. That continuation becomes a dead object—it doesn't do anything any more. That dead object is then stored, and somewhere in an event handler you register events as being related to that object. When an event occurs, you look up all the continuations that relate to that event, and then start those continuations up again. Instead of polling, you have a very low-overhead system. We've had reports from people that the performance of their applications improved dramatically this way.

Rate this Article

Adoption
Style

BT