Pathinfo mapping for element inputs

It's very common for the pathinfo of an URL to provide structured data to the element that handles the request. You can now easily setup rules that let RIFE do all the parsing of received pathinfos and construction of created pathinfos. This allows you to continue to work with regular exits and inputs, and automatically have usable and RESTful URLs with pathinfos created for you.

introducing pathinfo mappings

To make this possible, you have to use the <pathinfo> tag, for example:

<element id="MyElement" url="myurl/*" implementation="com.pakkage.MyImplementation">
    <pathinfo mapping="$year/$month/$day"/>
    <pathinfo mapping="$year/$month"/>

    <input name="year"/>
    <input name="month"/>
    <input name="day"/>
</element>

RIFE will now detect when an URL like this is called:

/myurl/2005/11/25

The pathinfo ('/2005/11/25' here) will be matched against the mappings that have been setup in the element declaration. This causes the year, month and day variables to be extracted. Their values will simply be provided as inputs to your elements.

You can declare as many mappings as you want and RIFE will process them sequentially according to their order of declaration. This means that the following URL will also be supported and only the year and month inputs will be populated.

/myurl/2005/11

regular expressions

By default, RIFE matches the following regular expression as values for pathinfo mapping variables:

\w+

It is possible to declare your own regular expression for each variable, like this for example:

<element id="MyElement" url="myurl/*" implementation="com.pakkage.MyImplementation">
    <pathinfo mapping="$year(\d{4})/$month(\d{2})/$day(\d{2})"/>
    <pathinfo mapping="$year(\d{4})/$month(\d{2})"/>
</element>

This will ensure that your pathinfo will only be mapped to the inputs when the variable actually correspond to the regular expressions that you declared (in this case they are enforced to be numbers and their length has been fixed).

optional input declarations

You also see in the previous example that haven't declared the inputs anymore. RIFE supports this since it will automatically add inputs for all the variables that you declared in the pathinfo mappings.

alternative variable syntax

For complex pathinfo situations, we support an alternative syntax that uses a curly brace syntax, for instance:

<pathinfo mapping="y${year}m${month}(\d+)d${day}"/>

This will map URLs like this:

/myurl/y2005m11d25

URL generation

RIFE will also automatically detect when you have a flowlink and datalinks that point towards an element that accepts pathinfo mappings. Any output values that are provided to inputs, will be matched to the supported regular expressions. The first pathinfo mapping for which all the input values are valid, will be used to generate an URL that contains the input values in the pathinfo. This provides you with a single point of declaration that automatically, consistently and easily handles the mapping of pathinfo in bidirectional manner.

[ top ]

Dynamic embedded element differentiators

In case you're using several embedded elements of the same element ID in the same template, you could already use differentiators before to tell RIFE that they are different and to be able to identify them.

However, we had no solution to for example use an embedded element for each row of a table with editable fields. Dynamic embedded element differentiators solve this.

The processEmbeddedElement(Template template, String elementId, String differentiator) method has been enhanced to support embedded elements with empty differentiators.

a simple example

Let's look at a short example. We are going to create a list with entries that each contain a form and a text input field. Each entry should be able to handle its own form submission, and display the received data afterwards. We are going to create one element that corresponds to an entry (ListEntry) and another one that corresponds to the list (List). The entry element is thus going to be embedded inside the template of the list element.

the List element

Let's look at the List element's template:

<!--V 'divs'/-->
<!--B 'div'-->
    <div><!--V 'counter'/--> <!--V 'ELEMENT:.ListEntry:'/--></div>
<!--/B-->

You clearly see that the ListEntry element ID simply has a colon and no differentiator. This means that RIFE will dynamically add a differentiator according to the value that has been provided for it in the processEmbeddedElement method.

the ListEntry element

The ListEntry element's declaration looks like this:

<element id="ListEntry" implementation="my.pakkage.ListEntry">
    <submission name="changeEntry">
        <param name="value"/>
    </submission>
</element>

has the following template:

<form method="post" action="[!V 'SUBMISSION:FORM:changeEntry'/]" name="form[!V 'differentiator'/]">
    <!--V 'SUBMISSION:PARAMS:changeEntry'/-->
    <input type="text" name="value">
    <input type="submit" />
</form>

and the following implementation:

public class ListEntry extends Element
{
    public void processElement()
    {
        Template t = getHtmlTemplate("listentry");
        t.setValue("differentiator", getEmbedDifferentiator());      
        print(t);
    }

    public void doChangeEntry()
    {
        print(getParameter("value"));
    }
}

Now, the implementation of the List element looks like this:

public class List extends Element
{
    public void processElement()
    {
        Template t = getHtmlTemplate("list");
        for (int i = 0; i < 10; i++)
        {
            t.setValue("counter", i);
            processEmbeddedElement(t, ".LISTENTRY_EMBEDDED", String.valueOf(i));
            t.appendBlock("divs", "div");
        }
        print(t);
    }
}

the result

You'll see a list with 10 entries and thus 10 input fields, they each handle their own submission without you having to do anything besides processing each embedded element with a unique differentiator.

[ top ]

JNDI support

The XML declaration of RIFE datasources now supports the <jndi> tag. This allows you to declare datasources that integrate with JNDI resources that have for example been setup in your servlet container.

For example:

<datasources>
    <datasource name="pgsql"> 
        <jndi>java:comp/env/jdbc/postgres</jndi> 
        <poolsize>5</poolsize> 
    </datasource>
</datasources>

[ top ]

Better Spring integration

RIFE's ParticipantSpringWeb now correctly supports a participant parameter that allows you to load an ApplicationContext XML file from a custom location.

Changes to RIFE's Datasource class now make it possible to provide it with a regular javax.sql.Datasource instance. This makes it easy to use RIFE's database features by using the same datasource setup as Spring. People for instance use this to create RIFE SQL builders inside Spring's IoC container.

[ top ]

Optional exit and output declaration

When you declare your elements inside the site-structure, you're now not forced anymore to declare exits and outputs. This makes sense, since be embedding the declaration inside the site-structure, these declarations can't be reused anymore.

So the following declaration:

<element id="YourElementId" url="the/url" implementation="your.element.Implementation">
    <exit name="exit1"/>
    <output name="output1"/>
    <output name="output2"/>

    <flowlink srcexit="exit1" destid="AnotherElementId"/>
    <datalink srcoutput="output1" destid="AnotherElementId" destinput="input1"/>
    <datalink srcoutput="output2" destid="AnotherElementId" destinput="input2"/>
</element>

can now be written as this:

<element id="YourElementId" url="the/url" implementation="your.element.Implementation">
    <flowlink srcexit="exit1" destid="AnotherElementId"/>
    <datalink srcoutput="output1" destid="AnotherElementId" destinput="input1"/>
    <datalink srcoutput="output2" destid="AnotherElementId" destinput="input2"/>
</element>

[ top ]

Additional callback methods

RIFE now supports the following new callback methods in the Callbacks interface:

beforeValidate(BeanType object)
afterValidate(BeanType object)

Beware, that RIFE's query managers (GenericQueryManager and ContentQueryManager) don't validate instances automatically before saving them. These callbacks will thus only be called when you call the validate(ValidationContext) method on your domain objects.

[ top ]

Arrival redirection

The <arrival> tag now supports an optional redirect attribute.

If this is present, RIFE will redirect the user to the URL of the target element of the arrival. If that element hasn't got an URL, RIFE will simply check whether the arrival element's URL ends with a slash. If that's not the case, RIFE will redirect to that one.

This feature makes it much easier to work with relative paths for resources like images, CSS files and JavaScripts since you can ensure that the entire subsite always has the same URL prefix that includes a final slash.

[ top ]

RIFE LiveGuide

RIFE's User's Guide needs a complete overhaul since it has been written more than two years ago.

In the meantime, all new features have been documented in our wiki's cookbook. This is however merely a collection of information without a global context or direction that guides the reader.

Emmanuel Okyere took the great initiative of writing a conversion script to create a wikified version of the old user's guide. He has added it to the wiki and I spent a few hours cleaning things up and splitting it into separate chapters.

So, if you're feeling like helping us out with RIFE's documentation: contribute to the LiveGuide!

If you're a bit shy about modifying the text itself, you can add comments and someone else will pick them up and make the changes.

[ top ]

Important fixes to the classloader

The classloader has been fixed in important locations to make it work without any problems in a combination of different scenarios. Occasional exceptions when using HotSwap are now not happening anymore. The automatic reloading of RIFE-compiled elements now also always continue to remember their updated version after reloads.

[ top ]