My friend JR pointed me to this trick which is detailed in RFC 2557

It turns out that by using a special data: URL scheme you are able to embed any mime data inside a HTML page, the format is as follows:

data:<mimetype>;base64,<data>

<mimetype> needs to be replaced by the mime-type of your data (image/png for instance) and
<data> is the base64 encoded string of the actual bytes of the file.

For instance, look at the source of the image below, or simply click on it and look at the URL in your browser's location bar.

This technique works in Firefox, Safari, Konqueror and Opera. I think it has great potential! Sadly I can't get it to work in Internet Explorer.
I already can imagine very useful applications for this: captcha images, image uploads in blog posts, ...

Congrats to Keith for releasing the next preview of Spring Web Flow. The announcement highlights that it supports continuations. Since RIFE was the first web framework to offer native web continuations in plain Java, I downloaded the source of this release to look at the samples. It's always interesting to see how others approach the same problem.

Much to my surprise, the Spring Web Flow continuations support was totally not what I expected. Every framework that claims to support continuations, offers this on the level of the implementation language, like this RIFE example snippet (full source):

    while (guess != answer) 
    { 
        // print the guess form and wait for a response 
        print(template); 
        pause(); 
             
        // obtain the guess 
        guess = getParameterInt("guess", -1);

        ....
    }

The main benefit of this is that you don't have to manually declare or handle any kind of flow anymore. You just rely on the control flow and scope of the implementation language and with special statements (pause() in RIFE), you break out of it and provide control again to the user. At the next request, the local variable stack will be automatically restored and the application will resume right where it left off (more in our presentation about this).

Spring Web Flow however only provides continuations in the flow declaration (can be both in XML and in Java), thus lacking what in my opinion is the single most interesting feature of continuations.

It seems that continuations are becoming a buzz-word, and like with all other buzz-words you should really check what is meant when people claim support for the technology. You might not get what you expected!

RIFE has been supporting Groovy for element implementations, site structure declarations and conditional template blockvalues for almost a year. When Groovy announced that they were going to reimplement the language parser completely and redesign the features of the language itself, I was pretty scared about how the migration to the upcoming version would be.

I finally took the plunge and upgraded to the latest version. To my surprise they were able to make these signification changes to the internals without changing the embedding API. That was already more than I expected! I really didn't have to change anything to RIFE at all! Even more, the bugs that I had reported were all fixed and I didn't have to make an exception for Groovy anymore with regards to the print method.

However, when running the tests I received a number of failures which are due to the minor backwards incompatible changes that the JSR version introduces.

These are the differences that mattered to me:

Heredocs

Instead of using <<<EOS to start a heredoc and EOS to finish it (Perl-style). They now adopted the Python style which I actually prefer much better. Just surround your text with triple quotes: """heredoc""" (example).

No support for splitting a single expression over several lines

We took the habit of using builders and chainable setters in Java, which allows us to write concise and intuitive code like this:

builder 
  .enterElement("groovy/test_groovy2elementinfo1.groovy") 
    .setId("ELEMENT1") 
    .setUrl("/test/element1") 
  .leaveElement(); 

However, the current version of Groovy requires the dot and the method call to be on the same line as the object it's being called upon, so they above code has to become:

element_builder = builder.enterElement("groovy/test_groovy2elementinfo1.groovy")
element_builder.setId("ELEMENT1")
element_builder.setUrl("/test/element1")
element_builder.leaveElement()

I find this a set-back and hope they'll solve this soon (bugreport).

The property keyword has been replaced with an annotation

I'm glad this was done since it's now possible to use the property literal in Groovy builders. Before I has to make an exception for RIFE's site structure and element structure declaration and rename property to prop. In the final 1.0 release, property will be usable in Groovy builders too.

Conclusion

I think that the Groovy team has done a great effort in formalizing the language and still keeping backwards compatibility as good as possible. To everyone who is hesitant to upgrade or start using Groovy, I'd say, don't be! If there's a time to try it out, it's now!

When browsing the web I stumbled into this article on TWiki's development wiki.

I was pleasantly surprised to see that the author had actually tried out RIFE in detail and looked further than the small initial setup. He correctly identified some of RIFE's unique features.

The site structure

The elements can be designed to be completely independent within a web application framework, and therefore completely reusable. For example, if someone designs a good table editor, it can be plugged in into twiki or any other wiki system without any change. The reason is: URLs and other info are generated by the framework rather than by the programmer.

I should add that this reusability is also possible thanks to RIFE taking care of the data flow as well as the logic flow. So it knows how to correctly maintain states for any element in any context (embedded, directly accessed, packaged in a sub-site, ...). This feature actually brings reusable modules with portlet-like capabilities right into the core framework, without having to perform a specific design or treat them differently!

Web continuations

Continuations are a way to overcome fundamental problem of designing a web-based application as a simple program flow application as opposed to event-based model, where it becomes very clumsy to decide next URl and to pass data around.

RIFE differentiates itself from other java solutions by automatically tracing and persisting the local variable skope and not requiring any setup at all in the site structure. A short presentation about continuations can be found here.

It should be noted that RIFE is not a continuations-only framework that insist on using them everywhere. We believe that the feature is only applicable for certain situations, for instance for 'islands of functionality' that should be finished completely or not at all (wizards, games, poll creation, dialogs, ...). Anywhere else, the site structure will assist you a lot in creating maintainable applications that handle state across the HTTP barier.

The template engine

This model requires all the logic to be put in the code(java) itself, and therefore, the templates can be very "clean".

Instead of criticizing the template engine on the looks of the tags alone, he realized the power of the logic-less engine and the simplicity of bi-directional templates that declare both value tags and block tags. He did skip over the include tag when reading the docs apparently: the I tag.