Support for Derby and One$DB/DaffodilDB databases

RIFE now fully supports Derby and One$DB/DaffodilDB in the database query builders and in every integrated framework:

• authentication,
• credentials,
• CMF,
• scheduler,
• resources,
• generic query manager.

Support for Cloudscape has been removed and has been replaced by the Derby support.

[ top ]

Important bugfixes and reduced memory usage

All known bugs have been fixed and many areas of the framework have been profiled in production to reduce memory usage as much as possible. Many thanks go to YourKit for providing our developers with free licenses.

Due to these fixes and improvements, everyone is urged to upgrade to this version.

[ top ]

Support for constrained beans

Besides the constrained properties, RIFE now has constrained beans. These constraints provide meta-data that isn't related to a single property but rather provides information about the entire bean instance. Some of these have been integrated with the database query builders (multi-column unique and default ordering), but others have been added for the benefit of external libraries like RIFE/crud and currently have no concrete interactions inside the core framework (associations and textual identifiers).

Constrained beans are declared is a completely similar manner as constrained properties, for example:

public class Personal extends Validation
{
    private String mFirstname = null;
    private String mLastname = null;
    private String mCity = null;
    
    public Personal()
    {
    }

    protected void activateValidation()
    {
        addConstraint(new ConstrainedBean()
            .unique("firstName", "lastName")
            .defaultOrder("city")
            .defaultOrder("lastName")
            .defaultOrder("firstName"));
    }
    
    public void setFirstname(String firstname) { mFirstname = firstname; }
    public String getFirstname() { return mFirstname; }
    public void setLastname(String lastname) { mLastname = lastname; }
    public String getLastname() { return mLastname; }
    public void setCity(String city) { mCity = city; }
    public String getCity() { return mCity; }
}

This will put a unique constraint on the firstName and lastName columns when you build a CreateTable query from this class like this:

new CreateTable(datasource)
    .table("personal")
    .columns(Personal.class);

Additionally, class-aware Select query builders will automatically order the results by city, lastName and firstName if no other order has been specified:

new Select(datasource, Personal.class)
    .from("personal");

[ top ]

Detection of URL length overflow

There is no standard limit for the maximum length of an URL, but currently the lowest common threshold seems to be 2048 bytes for Internet Explorer (http://support.microsoft.com/kb/q208427/). Since RIFE by default stores the state in the query string, there's a possibility that a query string makes this URL length limit overflow. RIFE now detects such an overflow and uses session state storage for that request only while logging a warning about it. This enhances the reliability of RIFE applications by picking the most REST-aware state storage method that's technically feasible without compromising the application's robustness.

[ top ]

Automatic preservation of serializable properties in the data flow

Before, RIFE's data flow only supported the automatic preservation of bean properties with types that could be mapped directly to String representations and recreated from those (primitives, primitive wrappers, arrays of these, Strings and StringBuilders). RIFE will now also detect properties that are Serializable and automatically serialize/deserialize them to Strings that can be passed along inputs, outputs and exits. Note that this can result in very long URLs, but thanks to the new detection of URL length overflow this will never make your application dysfunctional. You can of course pass these values around through POST requests instead or reduce the URL length by using session state storage.

[ top ]

Addition of database capabilities and compensators

RIFE has always had a layered approach to database interaction and persistence. We firmly believe that you need to know SQL and your target database before being able to make your applications perform as fast as possible. However, there are many basic operations that are totally analogue amongst database back-ends but differ in syntax. This is why we created the database query builders, which allow you to build your queries through a uniform API and rely on the engine to translate the queries into the appropriate syntax for your target database.

However, to collect the results of your queries, many common patterns exist that you shouldn't have to write manually. We collected those in the DbQueryManager, allowing you to be assisted with most of your custom queries. To cater for the regular easy persistence needs, we created the GenericQueryManager on top of the DbQueryManager and extended that into the CmfQueryManager to store rich content easily through the CMF.

In this release we're taking the database layer one step further and are starting to abstract functionalities that each database should have, but that not all of them provide easily. We call these functionalities 'capabilities'. If a database doesn't natively support a capability, it will use a compensator to still provide the requested functionality. RIFE knows for each supported database which capabilities are natively available and which ones need to be compensated for. Currently, the only available capabilities are 'limit' and 'offset' support., but we plan on adding others like 'distinct on'.

Capabilities are only used when you use RIFE's database query builders and execute them through the DbQueryManager (which implies the GenericQueryManager and the CmfQueryManager). However, they automatically kick in when you build a query with capabilities that aren't natively supported. This brings RIFE one step closer to database abstraction for regular query functionalities.

[ top ]

Support for internationalized requests and query strings

Unless you explicitly specify the character set in the content type attribute of an element declaration or set it explicitly in your code, each response will now default to the UTF-8 encoding. RIFE now also expects post requests to be in the UTF-8 encoding and you have to do nothing to your application to make this happen. All <!--V 'SUBMISSION:FORM:submissionName'/--> variables that you use as your form action will now automatically add the accept-charset="UTF-8" attribute to the form tag. All encodings that are used internally have also been updated to handle UTF-8 by default.

Sadly there's no standard for the character set encoding of URLs and it's not possible to reliably pass non-ascii data through the query string. Since RIFE has total control of your data flow, we are however capable to provide a workaround for this. All parameters that RIFE puts in URLs that are intended for itself, are now checked for non-ascii characters. If any of these are present, RIFE will use a custom encoding scheme to guarantee that your data is transferred along correctly. While those parameters will now not be human readable anymore, it allows international applications to be developed without worrying about possible data corruption while still behaving in a standard manner when only ascii values are transferred.

[ top ]

Complete isolation of embedded elements

RIFE now makes sure that any submission will only be handled by its originating element or those within its conceptual context (parent elements or preceeding elements). So if you have several submissions with the same name, it will not be picked up by an embedded element or a sibling element. For this to work, RIFE needs to be able to identify elements in a unique manner and it uses a method that respects server restarts or code maintainance. This means that active users of the web application or bookmarks will still continue to work when the application is maintained over time.

If you have several instances of the same embedded element in one template however, RIFE needs help to be able to differentiate the instances. This is simply done by appending a differentiator string like this:

<!--V 'ELEMENT:.THEELEMENTID:differentiator'/-->

This new submission behaviour might however conflict with some existing code that you have written, or you might want to actually have embedded elements react to a submission of an embedding element. Therefore, you're able to revert back to the previous behaviour by declaring the submission's scope to be 'global' instead of 'local' in your element declaration.

[ top ]