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.
* 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.