Home

In "Developing web applications with RIFE," Eddy Young writes about his RIFE adoption experience and how it increased his productivity and his joy during development a lot. After having used JSF for a while he is pleasantly surprised by the power and simplicity of RIFE:

In RIFE, templates, or views, are completely devoid of any logic. Anything in a template that is delimited with any of the FOUR tags can be easily manipulated by code in an element (or controller). The result is the simplest MVC web framework that I have ever encountered. Simpler than JSF, in fact.

...

RIFE has much more to offer. Other interesting features include continuations, seamless access to session and request parameters, and constraints validation. Anyone who is interested in learning more about this great framework should visit the project web site at http://www.rifers.org, join the mailing list or IRC channel and try a few examples. It does not take long to learn FOUR tags and the gain in productivity will be visible immediately.

However, Geert Bevin (principal author of RIFE) posted "Which Syntax Looks Best to You?," asking about what possible future or alternative format for RIFE's content tags would work best, in an attempt to address RIFE's learning curve. He presents a series of options, such as an XML processing instruction variant, Tapestry and Velocity-inspired variants, and XHTML tag possibilities as well.

There's one thing I've learned from leading an open source project: your users aren't always right. Just because they like the way things are done, it doesn't make it the best way to do it. Often, developers merely like something because they've learned it, and would rather not learn something new. Look at all the folks that prefer Struts, yet have never tried another web framework.

Personally, I like Velocity's variable style, which is now used by JSP 2.0. Most new Java web developers are going to learn JSP. If you can make the transition from JSP to your template syntax easier, you'll likely get more users.

I'm glad to see Geert raising the issue of Rife's templates. Its a framework that I seem to keep coming back to, and everytime I'm put off by the look of the templates :$

The other concern I have is (what seems like ) a large dependency on a lot of XML. How do people (Geert: you're excluded here!) find Rife in practice compared to some of the other frameworks available?

Hi, analog boy, actually RIFE's web engine doesn't depend on XML at all (http://rifers.org/wiki/display/RIFE/Site+structure+and+element+declaration+without+XML). However, it does rely on external declaration of your site's logic and data flow. This has immense benefits and basically allows RIFE to give a lot of powerful features for a little bit of consistency that you need to provide. Additionally you get a greatly documented overview of all the state transitions of your website. If you're interested I can go into detail of what the exact benefits are of these declarations.

... considering that there is not a single web framework out there that does not depend on XML declarations. The names of some of the attributes can be confusing (e.g. "inherits" is used where "requires" or "depends" would have been more appropriate), but when one gets in the RIFE mindset, everything seems so logical.

As for template tags, they may look ugly and un-appealing. However, as I write, there are only four base tags (V, B, BV and I) that one needs to learn. The rest of the "tags" are derived from those and present great opportunities for extensibility once understood. For example, localisation in templates is just a matter of adding the qualifier "L10N"; for marking errors, another qualifier "ERRORS" is used.

Another neglected feature of the templating system is its bi-directional nature. In RIFE, it is not only about writing to the template, but also reading from it. This does feel like JSP tags but is much simpler -- the case against too much XML certainly applies to taglibs, IMHO, but to the RIFE template tags.

I understand Geert's motives in trying to change the tag syntax to make it more appealing. Matt Raible is also right in his comments about "ugly" syntax scaring away potential users. Still, I think people should put in the effort to understand it as it is really powerful. Anyway, drop by the IRC channel (#rife on freenode) with your questions and the RIFE'rs will be all too happy to answer those.

... considering that there is not a single web framework out there that does not depend on XML declarations.

I'm sorry, but I have to jump in here. Just because most frameworks require you to declare all of your actions/elements/components etc. somewhere doesn't mean that all do. Specifically Stripes uses some neat classpath scanning tricks and reflection to locate and configure all ActionBeans automatically without anyone ever declaring a single one in XML (or groovy etc.). You simply write your ActionBeans and Stripes finds them.

The more places you have to keep artifacts in sync (and without compiler checking) the more problems you're going to have. It's because people accept current limitations as standard that we have such a hard time moving forward.

HI Tim,You're totally right when talking about ActionBeans only. However what RIFE offers goes way beyond that. By declaring a state machine, you never have to worry about your data flow, logic flow and their scope. You just use what is available and the web engine takes care of all the wiring. Besides that, it provides very advanced things like for example transparently wiring together implementations in different languages, callable continuations, snapbacks to previously executed elements, total URL relocatability of your application, automated pathinfo mapping, localized URLs, virtual sites (generated on the fly but still extensible: RIFE/Crud), configurable state storage, a three dimensional flow (look at this as being a site above a site in an AOP kind of way), portlet-like mini applications (embedded elements), and a whole bunch more ... All these with exactly the same API inside your elements and the sale object model. Again, thanks to a clear declaration of your state transitions, RIFE is able to intelligibly handle how data is transferred and stored.It goes far beyond simply saying which actions respond to which URLs.

Now I do realize that for the simplest case, mapping an element to an url this could feel a bit of an unnecessary overhead. We have planned to allow you to declare some things in annotations and do a similar auto-detection as you do. The problem you then get is that you don't have a single high-level overview source anymore of everything that goes on in your application. Having that is extremely helpful from a maintenance point of view or for doing team development. We'll need to carefully evaluate the impact of that.

HI Tim,You're totally right when talking about ActionBeans only. However what RIFE offers goes way beyond that. By declaring a state machine, you never have to worry about your data flow, logic flow and their scope. You just use what is available and the web engine takes care of all the wiring....[snip

Hi Geert,

Don't get me wrong, I'm not knocking RIFE. I know you have made a conscious choice to use XML to centrally declare site structure, and based on that decision you have the ability to do lots of neat things. And I don't think there's anything wrong with that. It has it's up sides and it's down sides. It'll work well for some applications, and possibly be overkill for others.

I was merely disagreeing with Eddy's assertion that it was a foregone conclusiong that things had to be this way because nobody has figured out how to do it differently.

The other concern I have is (what seems like ) a large dependency on a lot of XML. How do people (Geert: you're excluded here!) find Rife in practice compared to some of the other frameworks available?

I've written a small site with RIFE, 5000 lines of Java code. I find the XML to be overwhelming. It makes me feel scared to think that if I want to add a new page, I need to create a new element, create a new element XML file (or element in site file), then modify the site file to add datalinks, flowlinks, etc. It's intimidating and I don't like it.

I could've written my site declarations in java or groovy or something, but there's little direction in rife, too many ways to do things, and the examples use the xml format, so I did. I don't know if I would feel better about the amount of configuration if I used java or groovy for site declaration.

I want to put my comments in perspectiive a little bit. I hate web development. I've used WebWork 1.x and 2.x as well as JSP, Tcl CGI, and PHP, all for medium-small. I don't like any of them.

LOL.

Tcl CGI must have been a fun one. :)

Ruby On Rails isn't too bad for the medium-small stuff. I'm not a ROR zealot so please no flame wars.

Once again the Web Edge UI is where the pain point is for a lot of people. The frameworks don't seem to be the problem, since all of them have complaints -- the infrastructure is the main culprit.

HTTP/xHTML have reached critical mass and no gymnastics from any framework are going to solve expectations for Web 2.0 or whatever the buzz word is now. (We haven't even solved DHTML/CSS2 issues to any degree of satifisfaction nevermind injecting Dialog State Machines onto the browser). Yes, HTML browsers are ubiquitous but it's starting to feel like we're carrying a dead horse around in the development community and the inertia is counterproductive.

The other concern I have is (what seems like ) a large dependency on a lot of XML. How do people (Geert: you're excluded here!) find Rife in practice compared to some of the other frameworks available?

I've written a small site with RIFE, 5000 lines of Java code. I find the XML to be overwhelming. It makes me feel scared to think that if I want to add a new page, I need to create a new element, create a new element XML file (or element in site file), then modify the site file to add datalinks, flowlinks, etc. It's intimidating and I don't like it. I could've written my site declarations in java or groovy or something, but there's little direction in rife, too many ways to do things, and the examples use the xml format, so I did. I don't know if I would feel better about the amount of configuration if I used java or groovy for site declaration.

of course I can't speak for Keith, but I have the impression that he has always been frustrated about the limitations and problems that are inherit to web application development. When he started using RIFE he was very enthusiast and motivated by the new possibilities that were available to him. However, he's been using it for a small application on which he works a couple of hours every so many months in his free time. I think that now each time that he works on that application, he is confronted again with the differences between web development and standalone application development and gets frustrated every time over and over again. This is just my 2c from having spoken with him on IRC regularly.

Being a newcomer to web-development (and initially using parts of RIFE in a non-www context), I find the existing syntax to be perfectly suitable. Of course, I can't compare to other syntax, except as shown in the blog entries.

I look at the other examples, and I suppose I have the same reactions to other framework's syntax as people looking at RIFE's syntax. Lowering the barrier to entry is always good, but like Geert, I worry about the plugin landscape in future - how well would all those customised components/templates live together?

As for the current use of XML, the areas where it's used can also be done in other languages (groovy/java) but I've never felt the need to. The existing declarations for site, control and data flows are very expressive and flexible. Being able to tie elements together implicitly based on their inputs/outputs is just great; just create a flow and the data goes there.

It is true, however, that this level of flexibility (site, control and data flow definitions) might overwhelm and that some guidelines (other than by example) would help newcomers. Guess those are already on the TODO, along with better IDE tools :-)

That's not to say that there aren't areas that can't be streamlined - I've proposed a few changes in the past to make certain operations easier on the eyes (Geert has taken some of these on board, based on the overall RIFE philosophies in mind *g*)

One thing I feel RIFE does wrong and Wicket does right is the issue of templates. JSF and RIFE seem to bind Java objects to HTML code using hidden markup inside HTML comments (i.e. "ugly escaped code"). I much prefer Wicket's approach of binding components using wicket:id.

I think you got the wrong impression here. RIFE actually binds nothing to its templates, they totally stand alone as blueprints that you will use to create your final layout. They are also not tied to HTML, you can use templates for creating mail messages, CSS files, etc etc. The best way to look at them is when you think of Word or PowerPoint templates. Those files do nothing by themselves, yet they provide all the building blocks and placeholders to build your final document. All you do in RIFE templates is markup up those blocks and value placeholders, your Java code will then interact with them. You can find more information here: http://rifers.org/wiki/display/RIFE/Bidirectional+template+engine

I really think data binding is the way to go. While externalizing component references (Wicket, Tapestry, Facelets, Clay) does ease the visual editor, without actual tools, there's nothing really gained and the visuals can be skewed. It's kind of like Spring where everything's a generic <bean/>, but now everything is a <span/>. IMHO, that level of indirection doesn't help any participant on the project. For efficiency in templating and re-use, being able to semantically label or convey the literal intentions of the fragment or macro makes the most sense long term from a maintainability standpoint.

Jacob, I suspect you don't fully understand how RIFE's template engine works and what it does. Please don't look at it as anything else you know. It deceivingly simple, yet powerful. You actually do exactly what you suggest "semantically label or convey the literal intentions of the fragment", you never write any logic and you don't tie yourself to your object model. You merely say: "hey this is a block that dan be reused and this is its name, and here are placeholders where you an fill in data and this are their names". Being able to label these with terminology that's related to the layout and not your data model is extremely convenient too. The designer just worries about his own stuff and labels everything logically within the layout, your data model can evolve totally independently from that. You can also very easily change the templates of existing components without having to know anything about the data model that your application uses.

Geert, the simple 'placeholder' solution is exactly what I'm talking about. I would rather folly on the side of being able to expressively interrogate your object model in the UI than juggle the purist 'view separation'. My point was that we should all stop babying designers with our markup-- they shouldn't even really touch the pages that the programmers are working on (once they've componentized the content). You mention that they can easily change the templates of existing components-- what's cutting and pasting <!-- 'PARAM:foo'/--> any different than #{param.foo}? Can the designer freely change 'foo' without affecting the programmer-- but can the programmer change 'foo' without affecting the designer? You're right in saying that you would be less tied to your object model if you stuck to variables only in your templates. In looking at examples like this, I would rather use a <c:forEach/>, it's probably just personal preference.

Hi, for me the Label is the smallest interface i can have to the designer. I like to have no logic in my pages, this makes the life easier for me and the designer.

How the markup looks is a matter of taste, but to have the logic back in my template is not the same. The Designers i have worked with build static versions of the pages. After this you get the building blocks of your pages. To leave the logic out of the templates makes it very simple for the designer to change the things after inserting the labels.

Changing the name of a label / variable get you into trouble with JSP or RIFE.

It`s easier to write complex logic in my programming language and pushing the results back in the template, than handling it in the template.

Hi Jacob, I think that we're reaching a point where we'll have the agree to disagree since there's a lot in here that's closely tied to preference. I prefer expressing all my logic in Java, not in the middle of some other text with a reduced language. I also want to minimize the work that needs to be done when replacing templates or updating them. This is something that happens a lot in the applications we write since there are a lot of reusable components. You're right about the PARAM:foo tags being similar except that it's tied to the request parameters no the object model. There are only very little tag names like this and their usage is more an exception that a habit.

Now I understand your point of not wanting to tie the template to the data model. However, what if I have a POJO that contains the values I want to display? Do I really have to write a series of template.setValue() calls to map the values in my POJO to the names used in the template? Or is there a way to access those values with the standard "name" calls getName() convention?

Thanks for your help. I am appreciative of how responsive you are to your users, and of your attitude in general. You're setting a good example!

thanks for your kind words. You stumbled into one particular example of one particular feature that's not really the best way to do in normally. Also, the example is a bit outdated, I should change a few things. In practice I would do something like that as follows:

Geert, thanks for your reply. Indeed, the code you've included here makes more sense to me.

I'm sure you have a lot of TODOs but it may be worthwhile to update the examples on the web site. Personally, upon arrival to such a web site, my first reflex is to look for a section called something like 'Examples', 'Quick start', 'Sample code', 'Hello world', etc. I want to see what the code would look like using the framework. I suspect there are others who do the same.

It's too bad that some users would turn away just because of the template syntax; but I'll be honest, I've turned away from other frameworks just because I looked at the presented sample code and did not like what I saw.. which is why I think it may be worth it to update the examples to reflect what you recommend as the best way of achieving this.

(In the case of RIFE I had no doubt that there was a better way, so instead of turning away, I asked you. ;)

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.