RIFE 1.0 has been released. RIFE is a full-stack, open-source Java web application framework, providing request-based and component-based approaches and blending them together into a consistent component object model. This release marks a milestone for the API stability and the feature set.

The project has come a long way over the years and the goals have been constantly re-evaluated against production projects and newly introduced technologies. RIFE is now running on sites with 300000 daily page views, it is used for critical systems in a leading telephony company and has scaled down to embedded usage in mobile phones. We have also developed several other open-source projects with it like a forum (Bamboo), a blog (Elephant), an information bot (Drone), and a to-do list tracker (Bla-bla List).

Below are the highlights:

• Greatly improved documentation
• Backwards incompatible changes (to offer more consistency for future releases)
• Content syndication
• Callbacks
• SOAP improvements
• Attachment and HTML support for mail queue
• More production configuration parameters

The complete official announcement can be found at project's website.

I've used RIFE (and some of the projects based on it like the 'Bamboo' forum and the irc logging tool 'Drone' ) to build www.caosity.org, and I'm pleased to see RIFE hitting 1.0. I'll be updating to it soonish, and hope to expand the site using the new nifty features RIFE has added since the version I was happily using.

I've used RIFE for a few web-based development projects and it's great to see it reach 1.0 at last :). For me, the area it shines the most in is when embedding it in applications, especially its persistence framework.

The RIFE persistence framework works very well with HSQLDB (http://hsqldb.sourceforge.net) and weighs roughly 1.4mb in total (even after retroweaving). This made it ideal for integrating into applications for live deployment on client machines.

I especially liked the ease of development for storing and retrieving java beans. It was extremely easy to achieve simple tasks and almost as simple to take full control of the whole persistence lifecycle for my objects.

I did give other persistence frameworks a go, and other databases too; for my uses size was the dominating factor. It was great to find out I didn't have to compromise on functionality.

I've done quite a few projects with RIFE, and for me RIFE offers the best solutions to a lot of problems that web devs face. It simply is a best-of collection of features and tools. This isn't just another framework, RIFE has been proven in a number of websites with heavy use. Every time it has been used on a project, RIFE has shown that it is more than capable of providing the developer with the ease-of-use that reduces bugs and increases productivity and capable of providing the user or customer with the speed and stability that they demand.

RIFE deftly straddles the line between power and ease of use. RIFE has all the power you'll ever need, while still being easy enough to understand that you don't need to go looking at the documentation every time you use it.

Documentation is important to the developers of RIFE and as such it is well documented. If the documentation isn't enough, the community has also created mailing lists, forums, blogs and an IRC channel to make sure that RIFE is well supported. The documentation received a big upgrade since the last RC snapshot with a number of people contributing to the effort. So if you looked at it before, look at it again.

The developers of RIFE are also committed to teaching you how the framework works, there are a number of movies and example projects on the Rifers community site with more to come in the future.

RIFE offers a best-of framework with great features, great support and a great community. Stop by the IRC channel (#rife on irc.freenode.net) and everyone there will tell you how great RIFE truly is.

Seems ok I guess. But so what ? Looks like a poor cousin of tapestry with spring jdbc thrown in for persistence.

I'm sure lots of love and devotion went into it but is yet another framework necessary ? It's really hurting Java.

You believe that all of the frameworks are hurting Java, but really Java is hurting, so we're searching for the next abstraction layer. It's getting harder and harder to make all of the right choices in Java.

Rife uses an approach that was made popular in dynamic langauges...especially Lisp. (Read Hackers and Painters for a description of one such framework.) Seaside is now the flagship continuations-based framework. If you want to see the next generation web framework, look for ideas in Smalltalk, Python and Ruby, and think of ways to bring them back to Java.

Rife is absolutely moving in the right direction.

I've got deadlines, family, friends and other hobbies. I don't have time to compare 50 frameworks/languages etc. Competition is great..but 50! come on

I've got deadlines, family, friends and other hobbies. I don't have time to compare 50 frameworks/languages etc. Competition is great..but 50! come on

Which is why we went out of our way to explain the benefits and the features of RIFE on the site. We also created a user's guide, wrote clear and short targeted examples, recorded tutorial movies, created an in-depth presentation session, maintain a very complete wiki cookbook, release real-world open-source projects that use RIFE and wrote extensive javadocs.

You can already make up your mind quickly by browsing through any of these. It's also proof of our dedication to the project. This is not a 1.0 release without any documentation and with only part of it working.

The blazé attitude that says "we already have so much solutions, we don't need more" is getting tiresome quickly. Every day tens of new open-source projects are announced on freshmeat because people feel they can contribute something worthwhile. A fraction of those is actually really useful for you, but without all the rest that you don't find appropriate, your percentage would not even be there.

With RIFE we really think we provide a solution to many problems that none of the existing java web frameworks try to solve. If you don't find them interesting or don't want to take the time to even read through them, that's ok, but there are other people that are happy about our efforts.

If you have so little time, don't bother reading release announcements then and certainly don't waste your precious minutes by commenting.

It's worth 5 minutes of my time cause I may inheriting an application that uses some arcane framework.

I think you spent a lot of time on your baby and you don't want it disappear due to the de-facto framework: Spring/Hibernate...Appfuse solutions.

It's worth 5 minutes of my time cause I may inheriting an application that uses some arcane framework.

Imagine that ... wow it might even be a Smalltalk solution, or something in Ruby ... who knows, it might be Groovy if you're lucky, or any framework based on any of those. You shouldn't worry however, Appfuse solutions have taken the world as a storm and nobody is using anything else anymore because it does everything perfectly. You will never ever have to spend time on learning something new, you're now able to code exactly the same for the next 40 years to come. Happy now?

I think you spent a lot of time on your baby and you don't want it disappear due to the de-facto framework: Spring/Hibernate...Appfuse solutions.

Haha, now that's funny. Disappear? It has never really appeared on the scope of widely accepted Java solutions so what's to disappear? The fact is that I don't want to use anything else for my own company, because nothing I looked at gives the benefits of what we spent years developing. For the record, RIFE has been around since 2001, we just never gave it much noise. Many of the newer frameworks are thus at fault, not RIFE ;-)

I respect your work. I think we both have a common goal: be more productive.

I'm not alone in thinking the Java world has too many frameworks. It's a subject worthy of debate.

I respect your work. I think we both have a common goal: be more productive.

Exactly!

I'm not alone in thinking the Java world has too many frameworks. It's a subject worthy of debate.

I agree that there are many, but there are not too many. Imho there's a large amount of them that you can immediately discard. Those that are inactive, those that haven't got stable releases, and those that haven't got decent documentation.
You need a pool of ideas and projects that allow the best of breed to be isolated and pop up. It might not be RIFE, but that's not the point. The point is that if there would only be Spring you'd get into a mono-culture with little catalyzing ideas.
Finally, having a project out in the open and being perused by at least a handful of users certainly beats having to inherit from any custom framework or custom forks that have been kept in-house. Releasing something as open-source take a lot more effort when it's done properly. Trying to make things comprehensible to new users takes a big investment.

Actually, I think you're right on. There are too many frameworks. And I don't think it's good for Java.

But I just think that it's the symptom of a problem, and not the problem. Spring/Hibernate is a huge step in the right direction...but we've got much more ground to cover, especially for ultra-light weight development. I'm reading the proliferation of new frameworks/programming paradigms/design patterns as a suggestion that maybe Java's running out of gas, at least for problems like putting a web UI on a relational database.

In Beyond Java, I look at why Java was so successful, the compromises we made to get to this point, and what we have to give up for those compromises. I'm really concerned for Java, for simple application development. For the enterprise (2PC, heavy ORM, grid), I'm not concerned at all...

I'm really concerned for Java, for simple application development. For the enterprise (2PC, heavy ORM, grid), I'm not concerned at all...

I think that simple application development in Java has been neglected a lot. However, I think that Java is very suitable for it with the right tools and frameworks. I come from a history of scripting languages and created quite a number of large sites in Perl and PHP many years ago. We fell in a trap with PHP since the small sites started to grow, and even though we were using OO features and built a framework for it (RIFE's first prototype). We were having major problems with the language and the version upgrades. We had 60000 lines sites that needed to be completely checked manually because newer version of PHP broke API compatibility and some functions changed behavior in a subtle way.

Since we went the Java way and built RIFE with it, I can say that we quickly create simple websites and benefit of the features and the stability of the Java platform. There's however no problem for sites to grow since once more, simple sites from a couple of years ago have now grown to more than 120000 lines websites. Maintaining them has remained just as easy though.

I don't see the doom of Java coming.

With your work, we're one step closer. I like the way you're strething Java.

Not looked much into RIFE, skimmed the documentation, and I did think oh no not yet another Java Web Framework. I will try the video though.

I think Bruce is right. Many like myself in the Agile movement have been looking at ways to make web development simpler and faster and the search is moving us away from Java and into dynamic languages.

I've allways liked Smalltalk because of its' simplicity and elegance (tried learning OO using C++ back in 94 and gave up. Gave Smalltalk ago and suddenly OO made sense). Recently I have come to like Ruby which borrows much from Smalltalk.

It seems to me that a lot of research as gone on in computer science over the last 30 years yet the prevelant languages like Java and C# choose to ignore most of it.

Performance seems to be the reason why. Dumb down the language and increase development complexity. Fast at run time, slow at development time. Given the speed of modern machines this trade-off no longer makes sense (and is probably no longer true, since many optimisations can be performed at run-time inside the VM).

Attempts to make Java more productive tend to have the opposite effect (think of Application Servers and EJBs). I think JSF will go the same way too. What is missing is simplicity and conceptual integrity. XML configuration all over the place, and byte code manipulation, have got to be sure signs that a language is out of its' depths.

I'm convinced that the most important tool a developer has at his disposal is his programming language, and if productivity is important then there are better choices than Java (IMHO). If in doubt, take a look at Seaside, reason alone to move to Smalltalk.

IMHO the problem isn't the frameworks, but the language. I've got a sneaky feeling that RIFE has stretched Java, but the truth could be that Java has reached its' limits and we should all move on to a language that is much more dynamic.

I shouldn't reply to my own posts, but a thought has just come to mind. We've been here before. Some of you out there may remember Taligent (97?), an application framework project by IBM. It was supposed to deliver reusable frameworks across a number of vertical markets. The problem was that it didn't work.

At the time of its' demise I read an article by one of the Taligent developers. His explanantion for the failure of the project, was the managements' insistence that it was written in C++. Today it is quite popular to put down C++, but back then C++ was the cutting edge (much like Java today). C++ was just too rigid, and didn't give them the flexibility they needed (never mind the memory leaks that they didn't need).

At the same time as the failure of Taligent and other CORBA based component frameworks (remember OpenDoc ?), Java and J2EE emerged. More dynamic than C++, but still tied to a static view of the world. In the early days, Java/J2EE was a productivity boost, compared to C++ and CORBA, but as time has gone on people have become more and more disatisfied with it.

Whilst all this has been going on, dynamic languages like Smalltalk, have existed quitely in the background, ignored by most. Yet dynaic languages spawned the Agile movement, and are at the leading edge when it comes to OO frameworks (examples are Rails, Seaside and OODMS). Interestingly Sun has its own dynamic language, Self, but has chosen not to use it for anything other than research.

It may be time to move on from Java in the same way that we moved on from C++.

Many like myself in the Agile movement have been looking at ways to make web development simpler and faster and the search is moving us away from Java and into dynamic languages.
<snip>
It seems to me that a lot of research as gone on in computer science over the last 30 years yet the prevelant languages like Java and C# choose to ignore most of it.Performance seems to be the reason why. Dumb down the language and increase development complexity. Fast at run time, slow at development time.

I understand your concerns regarding Java compared to some of the more flexible languages. RIFE, Hibernate, EJB 3, etc. are evidence that the Java community is dedicated to improving simplicity and the power of the language. However the business case for strongly typed languages wins easily in an IS/application development environment where application maintenance is more than half of the overall cost. That is what most Java developers are doing and why most won't switch to scripting languages.

RIFE, Hibernate, EJB 3, etc. are evidence that the Java community is dedicated to improving simplicity and the power of the language. However the business case for strongly typed languages wins easily in an IS/application development environment where application maintenance is more than half of the overall cost. That is what most Java developers are doing and why most won't switch to scripting languages.

Hi,

Thanks for the response. I think this is a good debate worth having. To me, TTD is more than an adequate replacement for static type checking by the compiler.

I have not used a dynamic language on a large IS/application, and it would be good to here from someone who as.

It was the search for a Java Web Framework that supports continuations that lead me to RIFE. Some of the new additions to Java you speak about worry me. XML and byte code manipulation in Hibernate, annotations in EJB3. Both rely on add-ons which aren't intrinsic to the Java language. These add-ons create their own complexity in my opinion.

I don't want to have to learn another XML DTD or a load of new framework specific annotations, and I don't want my framework messing with my byte code at run-time either.

My feeling is that many of the goals of these Java frameworks could be better met with a dynamic language. Without the add-ons, development would be much simpler.

People have been writing IS/Applications in Smalltalk for years, and I'm not aware of issues with maintenance.

Have I missed something?

Paul.

To me, TTD is more than an adequate replacement for static type checking by the compiler.

Did I say TTD, want I meant to type was TDD, Test Driven Development. Having an executable (verifiable) design specification is a major step forward in ensuring program correctness (I believe).

I think TDD has shifted the argument in favour of dynamic languages when it comes to the static versus dynamic debate. Strong typing doesn't guarantee correct program operation, and not all type checking can be done statically. But I'm sure you're well versed in these arguments.

Still interested in alternative views,

Paul.

I've got deadlines, family, friends and other hobbies. I don't have time to compare 50 frameworks/languages etc. Competition is great..but 50! come on

Then check out some alternatives. New frameworks are coming out because the old ones are not getting it done. New languages/frameworks/programming models don't generally emerge unless we're prompted, and actively looking for a better way.

If you want a misguided example, look at IBM's new-found support of PHP. They're looking for simplicity...admittedly in the wrong places.

You believe that all of the frameworks are hurting Java, but really Java is hurting, so we're searching for the next abstraction layer. It's getting harder and harder to make all of the right choices in Java.

Or to rephrase from another point of view, Java is gaining more choices for creating web applications at a higher level of abstraction. If you have more choices, isn't it in fact easier - or at least increasingly possible - to make the "right" one? It seems to me that there are only a couple of things you can say for certain about the right choice: it depends and it's a moving target.

The proliferation of Java frameworks and their underlying concepts can, IMO, be more easily associated with innovation and growth rather than stagnation or "hurting." Does any other technology platform have as much going on right now in pursuit of that next abstraction layer? While great ideas are indeed being implemented in other languages, that's neither a new phenomenon nor does it mean that Java cannot absorb and benifit from them. Innovative, open source frameworks have arguably put Java on the leading edge of web development right now and I don't see more activity along those lines having the opposite effect in the future.

Furthermore, I don't think the new features in Java 5 have yet been exploited nearly to their full potential. Many of them (I'm thinking of generics, covariant return types and annotations) enable higher-level and more concise expressions and patterns. This means less code and should bring at least a few of the productivity advantages enjoyed by dynamic languages to Java.

Anyway, I'm spouting off a lot opinions about things that I'm sure you have more perspective on. Maybe I'm misinterpreting your tone, but your somewhat gloomy outlook on the current state of Java simply does not ring true with me.

Seems ok I guess. But so what ? Looks like a poor cousin of tapestry

What makes you say that it's a poor cousin of Tapestry? I've had people comment about the component object model that it's simple, consistent and much easier to use than Tapestry. I have no first-hand experience though.

with spring jdbc thrown in for persistence

It goes much further than simple JDBC templates. There are object oriented query builders, named parameters in prepared statements, a persistence layer that handles beans without setting up mappings, database feature abstraction and simulation, bean-oriented callbacks, a content management framework that integrates with the persistence layer, centralized meta-data facility (constraints) that is used to automate all this, ... and more. That's only the database part, there's a lot more ground that's covered.

I'm sure lots of love and devotion went into it but is yet another framework necessary ? It's really hurting Java.

We were already working on it when the initial version of Tapestry came out and that was the third internal prototype. We have been doing production applications with it for a long time and with a lot of success, as have other users. The 1.0 release is just a version number because it seems to be needed to get noticed. As far as usefulness and stability goes, it's been 1.0 for years. We like how everything is integrated and the global feel. For us there's no reason at all to devote time to another project and other people already seem to have appreciated our approach.

Excuse me. Please just think this reply as my curiosity. :)

Can someone who've experienced both RIFE and Wicket compare them briefly?

Thanks,
Trustin

Excuse me. Please just think this reply as my curiosity. :)Can someone who've experienced both RIFE and Wicket compare them briefly?Thanks,Trustin

Hi Trustin,

I think that it will be hard to find someone who has experience with both, considering that Wicket is relatively young and RIFE has a small user-base.

However, I can try to compare them briefly and if I say something horribly wrong, I'm sure that some Wicket users will correct me.

Wicket has a pure component-based approach to web application design. The page itself and every part in it that you want to manipulate are components in a very similar fashion as Swing. This makes you to consider componentization right away and structure your application accordingly. I'm sure that for many people this is great, but for us it just doesn't feel right.

RIFE on the surface looks like many other action-based frameworks since you bind your implementation to an URL (we call them elements) and inside your logic you retrieve the data where it's appropriate. However since we formalized both the logic and the data flow at the declaration level in the site, RIFE is aware of all state transitions that occur. It can use that to simulate an environment for each element and turn each element implicitly into a component. Each element can thus be embedded into your templates, grouped together into sub-sites which behave as individual components, re-use amongst applications in a binary form, distributed in a separate package, etc etc. The benefits of this are very tempting for us since anything you write in RIFE (even entire applications) are implicitly re-usable in different contexts. One example is our Bamboo forums. We had to add comment support to a news section of a customer. Instead of writing a simple featureless comment system from scratch, we referenced and embedded certain parts of the forum under each news post and behind the scenes created a new forum topic for each news item in a separated namespace. This provided all the features of Bamboo (mail notification, marking of unread posts, avatars, editing / deleting of comments, paging, message counting, ...) with very little effort and no code duplication. (you can look here for an example: http://www.netwerk.be/actueel/nieuwsbericht/1104)

One common approach I've seen between RIFE and Wicket is that we both seem to value simple packaging. Everything is referenced as resources in the classpath which allows you to distribute simple jars that contain everything to run your application.

Thank you for your comparison. It was great! :)

Trustin

Thank you for your comparison. It was great! :)Trustin

Glad it was helpful :-)

For the record, I only compared what is possible to compare: the web engine. Wicket only targets that part of web application development, while RIFE aims to provide a full stack that makes all the other tasks a lot easier and more intuitive.

We also try to adhere to a DRY philosophy together with centralized declarations of reusable parts. The whole stack that RIFE provides is able to benefit from this. In this sense, it has some of the benefits that Ruby on Rails also offers.

The fact that the RIFE stack is able to benefit from the close integration of each individual layer however doesn't meant that you can't use each one in isolation. We have built Swing and OpenLaszlo applications with RIFE, as well as an IRC bot. Some people are even only using the database layer in mobile phones due to the very low footprint.

I'm looking at the final proofs to my new book, Beyond Java. On Java or not, I think we'll all be using a continuation based approach in the next two or three years or so. It's just too compelling to do things any other way.

I also see these ideas in Web Flow (though not true continuations), Coccoon 2, and to a greater extent in Lakeshore. All of these frameworks are experimenting with the next generation web-based framework.

If you want to see the promise of this approach, check out Seaside, a Squeak-based framework. We're not all going to be using Smalltalk next year, but we could well be using the approach, and it does show why continuations are so important.

We're not all going to be using Smalltalk next year, but we could well be using the approach, and it does show why continuations are so important.

They indeed are, but people seem to be slow to pick them up. As you say, it'll probably still take some time before its usage in web application development will be widespread. For many parts it does make the most sense since your application flow is handled implicitly by the code that you write (ie. you don't have to extract and abstract it into another layer or language).
We have already been contacted about enhancing the continuations engine in RIFE by some very large companies and we're planning to make that the major new feature for the next release.

Thanks for the support Bruce and good luck with your new book, I'll read it when it comes out ;-)

Hello Rifers,

I have to say that the launch of your 1.0 version is very professional. Very nice website, even movies under "Theater". Rife has been on my radar for a long time, now I will finally give it a shot. Don't listen to those "Yet Another Web Framework" Guys. I you think that you can do better, then do it. Keep up the good work!

P. S.: I am watching your movies with my browser in fullscreen mode (since I couldn't download the big movie with wget and watch it standalone (there seems to be a flash loader mechanisms or something alike)) because I am running on a 1024x768 resolution TFT display.

Thanks for your kind and encouraging words Michael.

I enhanced the in-depth movie a lot and uploaded a new version together with two alternative formats. I also explained how to download it for local viewing. It can be found here:
http://rifers.org/rife_indepth_simple_blog

Have fun!

You rock. Thanks a lot. Especially for the introduction of these yellow explanation boxes. Much easier to understand now :-) And the idea of alternative formats is also great. Right now I'm enjoying the AVI (which I personally would recommend for Windows users, since at least on my machines flash movies generally sometimes cause the CPU to approach 100% or even crash (not only with your movies but GENERALLY, so that is not your fault, no need to take a action on your side); there seems to be a serious bug in Macromedia's flash player for Windows/Firefox/Opera).

I'm impressed with RIFE, I especially like the video, it really helps me to get a grasp of how everything fits together which I never seem to get when I read architecture documentation.

For the guy who doesn't have time to evaluate all the web frameworks out there may I suggest the criteria I use to evaluate web frameworks.

1. Persistance. How easy is it to write queries, how much Java do I have to write, how much XML do I have to write and maintain.

2. Model Layer. How easy is it to build business level functionality in components.

3. View Layer. How are templates handled, how clean is the seperation between the code and the HTML.

4. Controller Layer, How easy is it to map views to the model. do I have to write lot's of XML ?

The ideal web development structure for me would be -

1. Persistance. Generate all Value Objects, Create/Update/Delete code from a schema diagram. If I've modelled an entity I don't want to repeat myself by hand writing a value object POJO. All DB queries in standard SQL so I don't have to learn another query mechanism.

2. Model Layer, something like XDoclet I want to write one POJO and have all the XML/interfaces built for me. again (DRY) don't repeat yourself.

3. View Layer - I don't want code in my HTML or HTML in my code - RIFE is bang on there, however XMLC for me gives me a W3C DOM api with less markup.

4. Controllers - RIFE is pretty good here, although I wasn't happy that you have to write XML as well as actions/handlers.

So for me Ruby on Rails is pretty good at 1, 2 and 4. but no so good at 3.

I'm impressed with RIFE, I especially like the video, it really helps me to get a grasp of how everything fits together which I never seem to get when I read architecture documentation.

Thanks for the compliment. This is exactly why the video has been created. It still only touched a small part of the features though.

1. Persistance. Generate all Value Objects, Create/Update/Delete code from a schema diagram. If I've modelled an entity I don't want to repeat myself by hand writing a value object POJO.

We took the option to use the bean value object properties to drive the persistence functionalities. The advantage of this is that we can provide a very rich runtime meta-data system that we call constraints which can be used by other parts of the system too. Part of its power is also that it is instance based and not class based. This allows you to easily make exceptions for certain instances in callback methods, for instance.

All DB queries in standard SQL so I don't have to learn another query mechanism.

That's what we tried to achieve too with our object-oriented query builders. They allow you to create queries with the exact same semantics as SQL, except that they offer more power.
For instance:
* you don't have to construct them in a specific order since they only generate the SQL when they are used,
* you're also able to use named parameters in prepared statements since the query objects know what parameters they map to,
* using beans, a lot of the query writing becomes much easier since the statements can be auto-generated through introspection,
* you can create partially constructed queries that can be reused later or extended
* since the SQL doesn't have to be parsed, RIFE has a good knowledge of what you wanted to do and that allowed us to start implementing an abstraction layer that simulates features that are missing in certain databases (like limit and offset), we plan on implementing more

2. Model Layer, something like XDoclet I want to write one POJO and have all the XML/interfaces built for me. again (DRY) don't repeat yourself.

How would you see this working? I don't really understand what you mean by XML interfaces. Do you mean the fields of submission forms?

3. View Layer - I don't want code in my HTML or HTML in my code - RIFE is bang on there, however XMLC for me gives me a W3C DOM api with less markup.

Yes, but RIFE is usable with any language and uses the native comment syntax of it. You can also template mail messages with it. We actually use the template engine inside the framework to handle the differences in syntax between database SQL dialects. It can even be used to generate Java code.

4. Controllers - RIFE is pretty good here, although I wasn't happy that you have to write XML as well as actions/handlers.So for me Ruby on Rails is pretty good at 1, 2 and 4. but no so good at 3.

The small price of having to declare elements before they can be used offers the benefit of powerful componentization and total control of state handling and URLs. Many of RIFE's advanced features are possible since the web engine is aware of the complete data flow and logic flow. One in particular is what we call behavioral inheritance, you can read more information about it in this blog post.

Don't be fooled though, it doesn't have to be written in XML. We support Java, Groovy and Janino too for this. There is also nothing that prevents you from doing this at runtime either, which is exactly what we do in RIFE/Crud. This is a project that generates entire sites (like RoR's scaffolding) at runtime without code generation. It's all done at runtime and still customizable. Thanks to the component object model, everything that's provided by RIFE/Crud can be integrated into any other RIFE site. RIFE/Crud hasn't been released yet, but it's close to being done. If you're interested you can download it through Subversion. The 'run' build target will start up the samples with the included Derby database.