has been released. RIFE is a full-stack, open-source Java Web application component framework to develop and maintain Java Web applications. Included in this release are:
- Complete injection and outjection support for all element data (bijection support)
- Annotations support for element declaration
- Support for parallel and simultaneous continuations
- Fine-grained control over continuation trees and their invalidation
- Step-back continuations
- Stateful components
- Support for creating RIFE applications without any XML
- Support for reloading manually declared sites by site listeners
- Automatic recompilation of non-hotswappable or instrumented classes
- Generic Query Manager listeners
The project's documentation has vastly improved with many contributions from users to the LiveGuide
and the Cookbook
. New sections such as Tips & Tricks and Best Practices have also been added to the wiki
. A series of mini books is also being written for O'Reilly.
have been simplified so that new users are not confused by irrelevant artifacts, and new examples have been added to demonstrate some of version 1.5's features.
is now also available, as a demonstration of how to use RIFE in a full-blown, real-world application. It is a Java-oriented pastebin with syntax highlighting, diffing, private pastebins, image uploads, an administration interface and Drone bot notification.
As a side note, Geert Bevin, the project lead, has been nominated and accepted as a Java Champion, mainly for his work on the RIFE project and its support for native Java continuations.
What are your thoughts on RIFE? You've heard about it at TSSJS and JavaOne - what are your experiences with the framework?
... and I enjoyed using this framework a lot !
What I like :
- the templating system. Your view layer stays clear and simple.
- the data access layer. Getting a row out of a db table is dead simple, but you still have all the power if you know SQL.
- the authentication system : although it took me some time to grasp, it turns out to be fairly easy to add an authentication layer to your application.
I found it a bit difficult to get started though. The possibilities of this framwork are so big, you need to read a lot of things before you can start to make anything beyond the most simple webpage. Ofcourse this is partly because Rife is a full-stack. I should mention that the people on the mailing list, notably Geert himself, are very
Regarding the improvements in version 1.5, I personally like the continuations stuff. I don't think I will use the annotations, simply because I like having all the wiring and configuration in separate xml files.
Rife allowed me to develop faster a clean application which is transparant and flexible.
I've been doing J2EE development and architecture since 1999 (back when it was *really* painful), and have used a bunch of different toolkits and frameworks along the way. For my most recent two projects I have chosen to go with RIFE.
The biggest thing I like about it is its consistent feel. The functionality fits together in a way that feels like a coherent, architecturally clean whole rather than a hodgepodge of hacks and additions over time. But that doesn't mean its scope is limited; RIFE is chock full of goodies, from the innovative template layer to built-in RSS syndication support to ORM, and it all fits together nicely.
Of course, you can use just the parts you need and plug in other technologies for the rest (on one of my projects I'm using RIFE's ORM, but on the other I'm using iBatis and Spring, and RIFE plays nice with those tools) but when you use RIFE from top to bottom, you get some synergies that, to my knowledge, you won't find in any other Java framework.
Here's the classic example. You can specify, either by implementing a particular interface or by using a separate metadata class that sits alongside your business POJOs, various constraints on the values of the POJO fields. For example, you can say field X can only contain values from 1 to 10, field Y has a maximum length of 50 characters and is required, and field Z is an identifier. Then, with one API call, RIFE will create the table for you, using appropriate data types and creating whatever integrity constraints the underlying database supports to enforce the restrictions you specified in your metadata.
Okay, fine, other ORM tools do that too. But then you associate one of these objects with a form on a web page. RIFE's template system can generate HTML elements with the correct length limits based on the constraints. And the request handling engine (the "element" system) will, with a single call, load up a POJO instance with the values from the form. Then with one more call it will do input validation to make sure the user's input conforms to your constraints -- and if it doesn't, the validation results are fed back into the template engine to generate field-specific error messages (all of which are customizable at whatever granularity you need via a localizable properties file.) There is even a user-contributed module to do on-the-fly validation using AJAX.
Yes, as Henk said, there is a bit of a learning curve before you feel like you're really getting it, and there are still some parts of the system that are not documented as well as they could be. Truth be told I found it kind of frustrating at first, but eventually I got up to speed. And the documentation is getting better over time; I've written a bunch myself, as have others, so if you're looking at it for the first time now, you will have a much smoother ride than I did.
Once you start digging into RIFE you realize that this thing is not only already pretty technologically advanced and very capable, but that it has the potential to blow everything else out of the water as it progresses. This framework is definitely worth taking the time to learn more about.
When writing a webapp with RIFE, do I never need to bounce my servlet container for any reason? Or is it just write some code, then hit F5 in the browser?
The ability to just forget the container is involved is probably my favorite part of RoR.
You need to bounce the servlet container a lot less than with other frameworks, but until Sun fixes the deficiencies of the hotswap capability of the JVM, you will have to restart for certain kinds of changes to your classes, mostly adding/removing methods or fields.
However, that does not apply to element implementations (the classes that provide the logic behind a page or a component on a page). Since RIFE has complete control of the lifecycle of elements, it will automatically refresh them, even compile them for you, whether or not they've changed in a hotswap-compatible way.
If you're doing test-driven development, where all your non-UI code is developed in the context of unit tests that don't need a servlet container, you will be in pretty good shape; you'll only be running the container while you develop the UI code, which will typically be in element classes that RIFE can reload as needed.
If you're not doing test-driven development, you will have to fight the urge to put inappropriately large amounts of your business logic in element classes, because the auto reloading is so nice. (I guess you could start it off embedded in your element classes and migrate it out when it's working to your satisfaction.)
Steve is entire right here. Alternatively though, RIFE supports the major JVM scripting languages and you can freely mix them with Java to implement your elements. When those are used, no recompilation is of course even needed.
Ruby on Rails?
Hope I don't get flamed for saying the "R" word in an honest, no-troll-intended question.
I'm mostly a Java developer, but for kicks I just finished writing a little Web app in RoR, teaching myself Ruby and Rails along the way, essentially as an experiment and because I anticipated needing too long to try the same stunt with the Java tools I know. I found Rails to be almost painless with a lot of "free" automatic smarts, and coding in Ruby was generally fun and quick. Except for mild performance problems that I hope to address with custom DB queries, I'd consider using the same approach again.
So now, having experienced RoR, what I'd really like is to find someone who has experience with both RoR and RIFE and is thus able to provide a meaningful comparison. Partly because it's what I know and work with a lot, I'd like to do Web projects in Java-based frameworks, but hope to try one that's very painless in a similar way as I've found RoR to be. Does RIFE fit the bill?
it really depends on what you're looking for. RIFE's similarity with RoR is very little and probably limits itself to the fact that it's a full stack and that it has a strong accent on meta programming. You will find almost non of RoR's features and you will generally be on unfamiliar territory.
The learning curve is also not as flat at RoR's. The main reason for that is that we go far beyond the simple action-based model and that certain concepts must be understood first. After that initial ramp, you'll find that it gets very pleasant and intuitive to work with RIFE though (as many users confirm).
As far as the differences go, we value the importance of components and managed state handling, and we think that it's important to have meta programming without any code generation. Also, during the design of the framework we have constantly considered maintainability and the ability to create applications with a larger team, hence cleanly separating many concerns (which has obvious advantages and disadvantages). A last major difference is that instead of driving your application from database tables, we think that it's better to use your domain model instead as the central entity.
As you've already probably noticed, much of RoR's niceness comes from the Ruby language itself. Of course, there's very little that can be done in Java to achieve that. We did however manage to make some things a lot easier thanks to constraints
, meta data merging
If you're looking for a clone of RoR on the Java platform, RIFE doesn't fit the bill. You'd be much better off checking out Grails
. However, if you're looking for a productive framework with creative solutions that leverages Java as much as possible while pushing the JVM to its limits, RIFE will give you that.
Finally, it might be interesting to you to quote two famous RoR people on RIFE:
"RIFE is absolutely moving in the right direction.
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.
With your work, we're one step closer to simple application development in Java. I like the way RIFE is stretching Java."
David Heinemeier Hansson:
Despite the fact that we obviously look differently upon technology, I'd just like to recognize the good job you're doing pulling Java into a more modern world. RIFE certainly presents itself better than the vast majority of Java tech out there. One should almost think it was a Ruby project ;)."
For those that are interested in more specifics about RIFE, InfoQ posted a release announcement too and added a short interview
with questions that they asked me through email. People that don't know RIFE very well might get a clearer picture after having read the answers.
Congratulations Geert on RIFE 1.5!
RIFE has become my favorite web framework because of how well it is designed and how sound your resulting web application becomes.
I've tried 9 different Java web frameworks, including all of the "usual suspects", and RIFE comes out on top in my book for real-world development.
There are many outstanding features which are mentioned above as well as on the RIFE site. I'd like to mention that one of my favorites is how cleverly simple the templating mechanism is. No more having to remember 100 custom tags x 20 attributes per tag. Only 4 tags, with all of the logic in Java code, where it should be.
RIFE makes developing web applications a joy again, because you spend less time "fighting the framework". It reacts as expected and there are very few "gotchas", "patches" and "workarounds". It helps you with all of the common stuff and doesn't get in your way for those particularily complex scenarios.
As Steven has mentioned, the consistency of the framework is also excellent. Your applications stay modular and easy to understand when you return to your code or look at someone else's application.
Finally, I find that RIFE is the best of both worlds, as it provides the advantages of a "component-based" approach while also enabling to work with the "request-based" nature of web applications.
I am definitely a huge fan of RIFE. (I also like JMatter, but that's another post.) The continuations approach, the metamodel, and the wrapping approach to persistence are all attractive to me. RIFE absolutely takes Java in the right direction. Congrats on this milestone, Geert.
I used to have this idea that component based frameworks were the way to go, they do their best to hide all the request/response based details for you so you can focus on the logic you have to write. Still, they tend to get quite complex and you do have to understand the inner workings to be able to exploit them to the fullest or just to solve your problems in case you run into something caused by the framework you are using.
Because of the fact that these frameworks try to abstract everything away from you, you often end up having less control over your web application, like what urls your application will use or strict control over the look and feel of your application.
When I was looking for a framework for my latest project I had following requirements in mind:
- full control over application urls
- full control over the layout
- be able to model my data as objects(using ORM)
- be completely stateless (no data in sessions)
- support internationalization
After having played a bit with rife I knew rife was the perfect match.
As some of the other people here already said: "Rife is the best of both worlds", it allows you to componentize your software without taking away the control over your request/response based web application. I haven't used all features yet, but I do like everything I've been using so far and the templating engine is simply awesome!
But apart from the technical beauty of rife, I was most impressed by the community around rife.
Especially Geert who is a very passionate and devoted person, he always responds really quickly to whatever questions pop-up on the mailinglist.
I have to admit that the learning curve is quite steap, but as more and more documentation gets written every day, learning rife gets easier and today there is a lot quality documentation avaliable, so the entry barrier is quite low.
Besides that, there is always the community to help out.