Navigation

RSS 2.0 New Entries Syndication Feed Atom 0.3 New Entries Syndication Feed

Show blog menu v

 

General

Use it

Documentation

Support

Sibling projects

RIFE powered

Valid XHTML 1.0 Transitional

Valid CSS!

Blogs : Archives

avatar
< JavaPaste 1.0 released : pastebin with highlighting, diffing, private pastebins and image uploads   Nominated and accepted as Java Champion >
RIFE 1.5 released

Update: this announcement was posted on the front page of TheServerSide.com. If you have comments or are interested in what others have to say, it might be a good idea to head over there.

Below are the highlights:

  • Complete injection and outjection support for all element data (bijection) [ more ]
  • Annotations support for element declaration [ more ]
  • Support for parallel and simultaneous continuations [ more ]
  • Fine-grained control over continuation trees and their invalidation [ more ]
  • Step-back continuations [ more ]
  • Stateful components [ more ]
  • Support for creating RIFE applications without any XML [ more ]
  • Performance improvements [ more ]
  • Support for reloading manually declared sites by site listeners [ more ]
  • Automatic recompilation of non-hotswappable or instrumented classes [ more ]
  • Generic Query Manager listeners [ more ]

You can read the full changelog for more details.

This release can be downloaded from the downloads section, as usual.

Complete injection and outjection support for all element data (bijection)

RIFE will now automatically detect setters and getters in your element implementation and map them to the inputs, outputs, parameters, inbeans, outbeans, incookies, outcookies, and file uploads that have been declared. Note that this is purely on a name basis and you're not required to use annotation for this to be supported. However, when you do use the annotations-based declaration (as explained below), your declarations are nicely bundled and you have no duplication of the names.

[ top ]

Annotations support for element declaration

Annotations can now be used to create the element declarations and kick in when you declare an element implementation without an ID or file. All that is needed is the @Elem annotation on the element class.

The following conventions are being used by default:

  • if no ID is provided as an annotation value, the short class name will be used (without the package)
  • if no URL is provided as an annotation value, the lower cased short class name will be used

HelloWorld can thus be rewritten like this:

@Elem
public class HelloWorld extends Element {
    public void processElement() {
        Template template = getHtmlTemplate("helloworld");
        template.setValue("hello", "Hello world.");
        print(template);
    }
}

With the following site declaration:

<site>
    <arrival destid="HelloWorld"/>
    <element implementation="HelloWorld"/>
</site>

The element will automatically have the ID HelloWorld and be accessible through the URL "http://localhost:8080/helloworld".

From here onwards, you can start expanding the element declaration with annotations by adding attributes to the @Elem annotation. You can find detailed information in the Javadocs.

If you use a flowlink or a datalink with a destClass annotation value (instead of destId), the destination element class should also be annotated with @Elem for its ID to be obtained. RIFE assumes that this element has been declared in the site-structure and its ID will be evaluated inside the scope of the active sub-site. If you changed the ID of the destination element in the site structure, RIFE is not able to find that one since it's possible for an element class to be used several times with different IDs. If you need to reference an annotation element class that's part of another site structure, you can use the destClassIdPrefix annotation attribute.

To reduce the duplication of string literals for exit names, you can use the FlowlinkExitField and ExitField annotations. These allow you to annotate public final static String class fields instead of having to specify the exit names in attribute annotations of the main Elem annotation. Afterwards, it's easy to reuse these exit name fields inside your code to trigger the exits. This setup gives you compile-time safety for exit names.

For example:

@Elem
public class ProductListEntry extends Element {
    @FlowlinkExitField(destClass = EditProduct.class,
        destClassIdPrefix = "^Admin",
        datalinks = {
            @Datalink(srcOutput="productId", destInput="productId")
        })
    public static final String EXIT_EDIT_PRODUCT = "editProduct";
     
    @FlowlinkExitField(destClass = ShowProduct.class,
    datalinks = {
        @Datalink(srcOutput="productId", destInput="productId")
    })
    public static final String EXIT_SHOW_PRODUCT = "showProduct";
     
    private Product product;
     
    @OutputProperty
    public int getProductId() {
        if (product != null) return product.getId();
        return -1;
    }
     
    public void processElement() {
        // ... your logic ...
        exit(EXIT_SHOW_PRODUCT);
    }
}

Instead of declaring inputs, outputs, inbeans, outbeans, incookies, outcookies, submissions, parameters, submission beans and files inside the @Elem annotation, you can reduce name duplication by annotating them directly on setters, getters and submission method handlers (doSubmissionname format) with the InputProperty, OutputProperty, InBeanProperty, OutBeanProperty, InCookieProperty, OutCookieProperty, SubmissionHandler, ParamProperty, SubmissionBeanProperty, and FileProperty annotations.

Note that for the property declaration of parameters, files, and beans for a submission, RIFE will add them to the last declared submission. However, Java doesn't guarantee the order of methods in a class. That's why you need to use the Priority annotation to prioritize the order in which the annotated methods will be processed. The priority is not a traditional single integer that has to contain the correct sequential order, but it's an array of integers instead. This allows you to create logic prioritized groups and partition your methods like that. The first element of the array can for example be used to give a number to the submissions, and the second array element can then be used to indicate which methods belong to those submissions.

For example:

@Elem
public class MyElement extends Element {
    private String param1;
    private String param2;
    private String param3;
    private UploadedFile file1;
    private UploadedFile file2;
     
    @Priority({1})
    @SubmissionHandler
    public void doMySubmission() {
        // ...
    }
 
    @Priority({1, 1})
    @ParamProperty
    public void setParam1(String param1) {
        this.param1 = param1;
    }
 
    @Priority({1, 1})
    @FileProperty
    public void setFile1(UploadedFile file1) {
        this.file1 = file1;
    }
 
    @Priority({2})
    @SubmissionHandler
    public void doAnotherSubmission() {
        // ...
    }
     
    @Priority({2, 1})
    @ParamProperty
    public void setParam2(String param2) {
        this.param2 = param2;
    }
  
    @Priority({2, 1})
    @ParamProperty
    public void setParam3(String param3) {
        this.param3 = param3;
    }
     
    @Priority({2, 1})
    @FileProperty
    public void setFile2(UploadedFile file2) {
        this.file2 = file2;
    }
     
    public void processElement() {
        // ...
    }
}

The code above declares the submission 'mySubmission' and adds the parameter 'param1' and the file 'file1' to it. The second submission is 'anotherSubmission' and it will contain 'param2', 'param3' and 'file2'. You'll notice that the priorities '1,1' and '2,1' are used several times. This is because the order of the parameters and the files doesn't matter, only the first integer that ties them to the submission with the same priority value is important.

It's important to note that any method that doesn't contain a @Priority annotion will be processed before those that are prioritized. This means that you can still use a @Submission declaration inside the @Elem annotation and add parameters and files to it. The submission in the @Elem annotation will be the first that is processed and the non prioritized methods will be added to it since they come before the rest.

[ top ]

Support for parallel and simultaneous continuations

Continuations can run in embedded elements and any number of them can be active at the same time.

Below is the implementation of a page with multiple counters that all run independently as continuations with while loops.

The Counter.java element:

@Elem(url="", submissions = {
    @Submission(name = "decrease"),
    @Submission(name = "increase")})
public class Counter extends Element {
    public void processElement() {
        int counter = 0;
        Template t = getHtmlTemplate("counter");
        while (true) {
            t.setValue("counter", counter);
            print(t);
            pause();
            if (hasSubmission("decrease")) counter--;
            if (hasSubmission("increase")) counter++;
        }
    }
}

The counter.html template that is used by the element above:

<div>
    <r:v name="counter"/>
     
    <form action="${v SUBMISSION:FORM:decrease/}" method="post">
        <r:v name="SUBMISSION:PARAMS:decrease"/>
        <input type="submit" value=" - " />
    </form>
     
    <form action="${v SUBMISSION:FORM:increase/}" method="post">
        <r:v name="SUBMISSION:PARAMS:increase"/>
        <input type="submit" value=" + " />
    </form>
</div>

The main template that includes three counters as embedded elements:

<body>
    <r:v name="ELEMENT:Counter:1"/>
    <br />
    <r:v name="ELEMENT:Counter:2"/>
    <br />
    <r:v name="ELEMENT:Counter:3"/>
</body>

[ top ]

Fine-grained control over continuation trees and their invalidation

Continuations are perfect for expressing a transactional multi-step process that either fully completes, or not at all. At completion however, you most of the time have the requirement that the same process should not be able to be completed a second time (when a user re-submits the final form, for example a payment, this should not be accepted). It's now very easy to achieve this by using continuations by simply removing the entire continuation tree. This means that when the user re-submits, the corresponding continuation will not be found and instead of resuming at a previously paused location, the execution will jump back all the way to the initial step of the multi-step process.

The get access to the active continuation context and remove the associated continuation tree, you can use this simple call:

ContinuationContext.getActiveContext().removeContextTree();

Additional useful methods are available in the ContinuationContext class and allow you to introspect and manipulate the continuation hierarchy.

[ top ]

Step-back continuations

Continuations have always been used with a 'forward thinking' approach. With that I mean that when you resume after you pause, the next code is executed using the same local variable state. This results in explanations like: you continue where you left off, or continuations contain the remaining work to be done, ... With this release of RIFE, however, we allow you to step back to a previous location in the code. Instead of resuming where you left off when you paused, you can now also resume where you left off in the previous continuation.

The availability of this features makes it extremely easy to add 'back' submit buttons to multi-step flows. You just have to detect that it has been clicked and execute the stepBack() method call. This use of continuations doesn't require an intermediate user reponse step to continue. Instead, it captures the state of the current continuation and immediately resumes where the previous continuation resumed (not the last pause() call, but the one before).

For example (you can try out an online version of this example on the rifers.org website):

// handle the submission of the shipping details
do {
    generateForm(template, order);
    template.setBlock("content_form", "content_shipping");
    print(template);
    pause();
     
    template.clear();
    order.resetValidation();
    fillSubmissionBean(order);
} while (duringStepBack() || !order.validateGroup("shipping"));
 
// handle the submission of the credit card details
do {
    generateForm(template, order);
    template.setBlock("content_form", "content_creditcard");
    print(template);
    pause();
     
    template.clear();
    order.resetValidation();
    fillSubmissionBean(order);
 
    // if the form input button with the name "back1" was
    // pressed, a step-back continuation is executed,
    // this makes the flow jump to first pause() call in
    // this code snippet (not the pause call inside this
    // while loop)
    if (hasParameterValue("back1")) stepBack();
 
} while (!order.validateGroup("creditcard"));
 
// provide an overview of everything that has been submitted
template.setBean(order);
template.setBlock("content", "content_overview");
print(template);
 
// remove any continuation contexts that are active in this tree
ContinuationContext.getActiveContext().removeContextTree();

Note that the first loop contains an additional check: "duringStepBack()". This is needed since the "shipping" group of the OrderData bean is already valid, otherwise it would not have been possible to get to the second while loop. Without the check for an active step-back continuation, the first loop would simply terminate immediately after the step-back and the execution would arrive at the location of the "stepBack()" method call.

A very nice feature of this setup is that the data of the second step (the credit card details) is filled into the bean but not validated when the back button is pressed. Users can thus fill in incomplete data, go to the previous step in the wizard without being interrupted, change the data in the first form, and after submission they will see the same incomplete data that they entered before stepping back.

[ top ]

Stateful components

RIFE now makes it very easy for element instances to indicate which state needs to be preserved for them (in case you don't want to use continuations for this).

You simply create datalinks that point back to exactly the same element as the one they originate from. These are called reflexive datalinks. The data that's available through the connected outputs will be collected by RIFE and provided as inputs to the element when it's processed the next time. Note, this seperates out the collected data for each individual element instance you use on a site, even for embedded elements. While this is the behavior you would expect, it's worth pointing out that the data is not preserved globally for all the elements of the same type.

Let's look at the same counter example that we used to demonstrate parallel continuations, only this time it uses stateful components (you can try this version out online).

The element implementation Counter.java:

@Elem(
// Setting an empty URL, makes the submissions target the element that embeds
// the embedded Counter elements. Without this declaration, each embedded
// element would become the main element after the submission (since it has
// its own URL).
url="",
// This data link connects the 'counter' output to the 'counter' value. The
// element might have changed the counter property value in the meantime
// (after an 'increase' or 'decrease' submission). The reflective datalink
// will pass the output value to the input at the next submission.
datalinks = {@Datalink(srcOutput="counter", destInput="counter", destClass=Counter.class)}
)
public class Counter extends Element {
    private int counter;
    @InputProperty  public void setCounter(int counter) { this.counter = counter; }
    @OutputProperty public int getCounter() { return counter; }
     
    @SubmissionHandler
    public void doDecrease() {
        counter--;
        processElement();
    }
     
    @SubmissionHandler
    public void doIncrease() {
        counter++;
        processElement();
    }
     
    public void processElement() {
        Template t = getHtmlTemplate("counter");
        t.setValue("counter", counter);
        print(t);
    }
}

The counter.html template that is used by the element above:

<div>
    <r:v name="counter"/>
     
    <form action="${v SUBMISSION:FORM:decrease/}" method="post">
        <r:v name="SUBMISSION:PARAMS:decrease"/>
        <input type="submit" value=" - " />
    </form>
     
    <form action="${v SUBMISSION:FORM:increase/}" method="post">
        <r:v name="SUBMISSION:PARAMS:increase"/>
        <input type="submit" value=" + " />
 
    </form>
</div>

The main template that includes three stateful counters as embedded elements:

<body>
    <r:v name="ELEMENT:Counter:1"/>
    <br />
    <r:v name="ELEMENT:Counter:2"/>
    <br />
    <r:v name="ELEMENT:Counter:3"/>
</body>

[ top ]

Support for creating RIFE applications without any XML

The last part of the architecture of a RIFE web application that still required XML, was the repository setup. You needed to provide a participants.xml file to declare all the participants in the repository. This can now be removed by creating your own LifeCycle implementation. To use this you have to modify RIFE's standard web.xml file and use a lifecycle.classname init-param instead of the rep.path init-param.

For example:

<web-app>
    <filter>
        <filter-name>RIFE</filter-name>
        <filter-class>com.uwyn.rife.servlet.RifeFilter</filter-class>
        <init-param>
            <param-name>lifecycle.classname</param-name>
            <param-value>LifeCycle</param-value>
        </init-param>
    </filter>
 
    <filter-mapping>
        <filter-name>RIFE</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
</web-app>
 

Then you can create your own LifeCycle class like this:

public class LifeCycle extends RifeLifecycle {
    public LifeCycle() {
        BlockingRepository rep = new BlockingRepository();
        rep.addParticipant(ParticipantSite.class);
        rep.runParticipants();
        Rep.setDefaultRepository(rep);
    }
}

Don't forget to set the default repository in your custom lifecycle, since much of RIFE relies on the presence of that.

[ top ]

Performance improvements

A lot of work has been done to improve the performance both for development as for production.

These two are the most noteworthy:

  • When you use the "session" state storage mechanism, instead of the default "query" state storage, RIFE will do its best to prevent data from being encoded and decoded to and from strings. This makes the performance of applications with complex state management a lot better, at the expense of having to manage the state on the server-side.
  • During development time, RIFE constantly checks for changes in the site structure so that it can reload them on the fly. Before, this was done for every single request. This made the performance drop dramatically for complex sites since the checks were done for each and every CSS file and image in the site too (since RIFE is setup as a filter by default). RIFE is now by default setup to only perform these checks once every 10 seconds. This behavior can be configured through the AUTO_RELOAD_DELAY configuration parameter. It's default value is 10000. Of course, auto reloading can be turned of for production deployments, you can find the details on the wiki.

[ top ]

Support for reloading manually declared sites by site listeners

When you create a site through the Java API of the SiteBuilder class, you're able to include sub-sites that are declared with XML. These are registered as reloadable resources and their modification time is stored and checked regularly if the SITE_AUTO_RELOAD configuration parameter is set to true. The same happens for the compiled class files of the element implementations. However, since you manually declared the main site using Java, RIFE can't automatically rebuild it (which is what it does when you create a site using XML). You can now however add a SiteListener to your site that will receive a notification whenever RIFE detects that any of the site's resources has been modified. In your SiteListener implementation you can then rebuild the site and make it the new default instance that is used by RIFE.

For example, this is a custom site participant that does just that:

public class MySiteParticipant extends BlockingParticipant {
    private Site    site;
      
    public void initialize() {
        SiteBuilder builder = new SiteBuilder("main");
        builder
            .enterElement("YourElement")
                // ...
            .leaveElement()
          
            // ... other elements and sub sites
            ;
                  
        site = builder.getSite();
        site.addListener(new SiteListener() {
                public void modified(Site modifiedSite) {
                    initialize();
                    modifiedSite.populateFromOther(site);
                }
            });
    }
      
    protected Object _getObject() {
        return site;
    }
}

[ top ]

Automatic recompilation of non-hotswappable or instrumented classes

RIFE will now always recompile a changed Java implementation of an element if the source is available through the classpath, the ELEMENT_AUTO_RELOAD configuration parameter is set to true and a Java compiler is available. This allows you to add or remove methods to your element imlementations, to change the annotations, to modify the logic of a continuation element, etc. All without restarting the servlet container.

Note that you have to be careful about your application classpath setup here. You have two options:

  • Let RIFE compile all your element implementations:

    To make this possible you have to setup your IDE to not compile the element Java files. This is probably the easiest done by seperating them into a dedicated directory and setting up different compilation rules for them.

  • Let your IDE use hotswap to recompile the changed element implementations:

    RIFE will detect that a class file has changed and re-compile it from source when needed. Each IDE has a different approach to using hotswap: Eclipse does it automatically when you save a Java file when the application is running; X-develop, IDEA and NetBeans make you trigger hotswap explicitly by selecting a menu item or py 5clicking a toolbar button. If you get a message from the IDE, saying that hotswap doesn't support the changes in the reloaded classes, you can ignore it. RIFE's classloader works around this by loading a new copy of the element class.

In either case, you have to take extra care if you setup an application structure yourself outside the traditional WEB-INF web application structure. RIFE's classloader expects a standard structure by default. Otherwise, you have to make sure that the Java classpath contains all the required directories and jar files, and you have to tell RIFE which parts are only part of the web application (the classpath elements that would go into WEB-INF/classes or WEB-INF/lib). This is done by providing them as paths through the rife.webapp.path JVM property at application startup.

[ top ]

Generic Query Manager listeners

Callbacks have been available since RIFE version 1.0. We now however also introduced GenericQueryManagerListeners. These are similar to callbacks, except that they are associated with one particular GenericQueryManager, while Callbacks are associated with your domain model. Listeners are also only called as a notification mechanisms, they don't allow you to intervene in the execution flow. Listeners are called before 'after' callbacks.

[ top ]

Full changelog

2006-07-13 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * RELEASE 1.5

2006-07-12 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Updated mime type property for the examples highlighted source code.

  * Updated changelog

2006-07-11 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Placed empty target types on annotations that can only be used nested
  inside enclosing annotations.

  * RIFE-284 : @Exit annotation should be valid on fields

  * Ant build file fixes

2006-07-10 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Minor refactorings concerning state store extensibility

  * Generated highlighted sources of the latest version of the examples.

  * Example refactoring and source code re-formatting

  * Changed the dominant template tag syntax in the examples into
  <r:v name=""/>

  * Very rare NPE fix.

  * RIFE-291 : Annotation destClass attributes should also support a
  destClassIdPrefix attribute

2006-07-09 Geert Bevin  <gbevin[remove] at uwyn dot com>

  * Compilation fixes for windows and environment setup fixes for windows.

  * Tmp path fixes

  * Updated project files.

  * RIFE-281 : INVALID should suppress/clear MANDATORY message
  
2006-07-08 Geert Bevin  <gbevin[remove] at