Blogs : Archives
|
|
| < RIFE makes the SD Times | Java In Action rocked > |
|
It seems that there are a lot of misconceptions and prejudgements regarding the RIFE framework. Last week I read the most striking collection of these in a framework comparison document that was written for the Scooby project. Basically, everything they state is completely wrong. It feels like they merely based their findings on unresearched assumptions from reading a few example snippets. Here are the facts that set straight some very common misconceptions: AgilityMisconceptionSome agility is lost due to the fact that there are no control structures in the templating language (see the templating section below.) While this may be more philosophically sound, for our modest templating needs it is probably over-engineering
FactRIFE will automatically reload when the Java source code for the element implementation changes if the elements were not compiled manually before. This extracts the logic from the templates themselves while still providing you with a development environment that rarely needs to be restarted. Apart from Java, a lot of JVM scripting languages are supported and you can use them instead or together with Java for the implementation of elements. These will of course also be auto-reloaded. More information here: MisconceptionThe amount of XML configuration is similar to tapestry. This is a burden and should be avoided in favor of sensible defaults and ad-hoc configuration inside regular Java code.
FactThe XML is just one way to declare the logic flow and data flow of your application, these declarations are fully supported in Java, Groovy and Janino and can even be auto-generated (RIFE/Crud). While these declarations might seems like an unnecessary overhead, they offer a lot of benefits once your application grows bigger than a couple of pages. It makes it very easy to see exactly what goes on, and the engine has complete knowledge of all state transitions which is the foundation of its advanced features (componentization, etc). Don't be fooled by the 'no-configuration' movement, they just shift the overhead elsewhere and often this means that it's scattered and less easy to find or maintain. More information here: ComponentizationMisconceptionThere's not support for componentization, RIFE is just an action-based and request-based framework. You can however define parameterized blocks of HTML and use them on many pages which provided some level of reuse.
FactRIFE is componentized at the core. Everything is built for it, an excerpt from the homepage of http://rifers.org: "Instead of mapping actions and controllers directly to the request, RIFE provides a component object model that behaves identically in many different situations such as individual pages, intercepted requests, portal-like page fragments and integratable widgets. Components can be wired together and be packaged as groups that are components in their own right. They can be distributed separately and be seamlessly integrated into any other RIFE project. This provides the same form of reusability as component-based frameworks, but with the raw control of the request-based approach." RIFE provides many levels of componentization, and doesn't merely focus on widgets or portlets. When I demonstrated our component approach to people during Java In Action, they were struck by the consistency and the power of it. However, it took a slight nudge to make their thoughts wonder away from the usual Swing-based approach of the other Java component web frameworks. Performance, scalability and stabilityMisconceptionRIFE is a young framework that just released its first stable version. It has never been used in production and will probably not hold up when used for sites with a large number of visitors.
FactRIFE 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. The framework has been under development for over 4 years and we have used it for quite a number of production sites and products. It has proven its use and applicability in real-world projects. Performance is very good, as is scalability. Large featuresetMisconceptionRIFE is a very interesting approach to web-app development, featuring an end-to-end solution all the way from DAOs to the view. However, this feature set is too large and not appropriate for our project, we don't want the overhead of having to carry around what we don't use.
FactNothing requires you to use all features. We have users, that for example only use the database layer inside mobile phones without any web-related features. RIFE is only a 2MB jar file without any dependencies. That file is literally all you need (besides JDBC drivers, etc, of course). This categorizes it as a lightweight solution that happens to have a lot of features. If 2MB should be too much and you only need the database abstraction layer and the persistence framework, we even provide a build target that only includes those features for one particular database. The resulting jar file is only 700kB large. Just use what you need. LocalizationMisconceptionRIFE has no support for localization or internationalization, we need a solution that takes care of this for us.
FactRIFE has probably the most extensive support for localization that you'll find in a web framework. The core development team is located in Belgium, a country with three official languages: Dutch, French and German. We can't afford being unable to support this. We thus fully support localization, even up to the URLs. More information here: ContinuationsMisconceptionRIFE's support for continuations looks cool, but I don't want to have to build an entire application like this. Continuations-based frameworks lock you into their way of doing things and force the developers to implement functionalities in a linear fashion.
FactRIFE offers continuations as one way of handling the flow of your web application, you aren't required to adopt this throughout your whole project. Just like any feature, they have their advantages and drawbacks. Our site-structure externalizes the flow declaration and it is still the recommended way to do so for the global flow of your application. We recommend the use of continuations when you have multi-step operations that are a logic entity where it doesn't make sense to access intermediate steps directly, wizards are a typical example of this. We call these 'islands of functionality' and you can have any number of them. They are unrelated to each-other and can be linked together through the externalized flow declaration. This gives you the best of both worlds. If it doesn't make sense to use continuations, just don't. |
||||||
Comments |
||||||
|
||||||
Add a new comment |
||||||
|
||||||
| < RIFE makes the SD Times | Java In Action rocked > |