Kuali Rice 2.4.0-M1-SNAPSHOT Release Notes

This version of Rice includes many improvements to the Kuali Rapid Application Development (KRAD) Framework. Below is a summary of the larger new features and you can learn more about them in the KRAD Guide which is also now publicly available with this release. Also review the Jira list at the end of this document to see the smaller items.

Kuali Rice 2.4.0-M1-SNAPSHOT can be downloaded from the Rice website at http://kuali.org/rice/download.

There are three different distributions of Rice available: source, binary and server. Please read the Installation Guide for more details on each of these distributions.

Applications can also consume Rice from the maven site at http://search.maven.org/#search|ga|1|org.kuali.rice.

API Documentation can be found at http://site.kuali.org/rice/2.4.0-M1-SNAPSHOT/apidocs/index.html

Formal documentation can be found at http://site.kuali.org/rice/2.4.0-M1-SNAPSHOT/reference/html/index.html. This documentation is still in the process of review and update which will continue through subsequent releases, so please follow the notes in each document to report any outdated information.

If you encounter any difficulty, please don't hesitate to contact the Rice team on our public collaboration mailing list at <rice.collab@kuali.org>. Please indicate that you are using the 2.4.0-M1-SNAPSHOT version of Rice.

MySQL and Oracle scripts for performing these updates are available in the following locations in the Rice distribution downloads:

With the 2.2-m1 release are two scripts that will automatically convert changed bean names, property names, and CSS classes. These scripts are located in the Rice project within folder: scripts/bean-rename These are groovy scripts. To run a groovy script:

The first conversion script is named BeanRename.groovy and renames bean ids and property names. This will find all XML files in the directory from which the script is run, and all sub-directories. Therefore you should first copy BeanRename.groovy and the file beanReplacements.txt to the directory which contains your UIF XML files, then run from that directory.  Please note if you have XML files that contain KNS definitions (such as the LookupDefinition or MaintainbleDefinition), this conversion script should not be run on those files. The second script is named CssRename.groovy and renames CSS classes. This will find all CSS files in the directory from which the script is run, and all sub-directories. Therefore you should first copy CssRename.groovy and the file cssReplacements.txt to the directory which contains your CSS file, then run from that directory.

The following changes impact KRAD UIF configuration (XML). Mostly these should be covered by the Bean/CSS conversion script documented in the Upgrade Guide section of this document.

public void addGrowlMessage(String growlTitle, String messageKey); 
public void addGrowlMessage(String growlTitle, String messageKey, String... messageParameters); 
public void addGrowlMessage(String growlTitle, String growlTheme, String messageKey); 
public void addGrowlMessage(String growlTitle, String growlTheme, String messageKey, String... messageParameters);

Renamed clientSideJs in Action.java to actionScript. Any client side javascript that the user needs to be executed will now have to be set using the "actionScript" property instead of "clientSideJs".

handleIncidentReport() in krad.message was changed so that it no longer replaces the view with the incident report. It checks if the content is incident report view and then returns true else it returns false. The view is now replaced by the updateViewHandler() in krad.ajax.

ajaxSubmitForm(methodToCall, successCallback, additionalData, elementToBlock, errorCallback) has been changed to ajaxSubmitForm(methodToCall, successCallback, additionalData, elementToBlock ,  preSubmitCall). This in turn calls the ajaxSubmitFormFullOpts(methodToCall, successCallback, additionalData, elementToBlock, errorCallback, validate,preSubmitCall, returnType).

The following new methods have been added to krad.ajax.js

1. actionInvokeHandler(component)  -  Instead of calling the jQuery('#kualiForm').submit(), it has been replaced by the actionInvokeHandler(component). Component is the element on which the action has been invoked. This method checks based on the data-attributes whether it is an ajax submit or a non ajax one and then calls one of the submit       methods.

2. ajaxSubmitForm()  - This in turn calls the ajaxSubmitFormFullOpts() with the validate flag set to false.

3. validateAndAjaxSubmitForm()  - This in turn calls the ajaxSubmitFormFullOpts() with the validate flag set to true.

4. ajaxSubmitFormFullOpts() - Submits the form through an ajax submit, the response is the new page html runs all hidden scripts passed back (this is to get around a bug with premature script evaluation). It is similar to the old ajaxSubmitForm() but has some additional parameter which allow for providing hooks  for  successCallback,errorCallback and preSubmitCalls. It also takes a validate flag as well as a returnType. A returnType is used to request data from the server but the server may override it. If the validate flag is set it validates the form and  proceeds if the form is valid. If a presubmit call is specified then it executes that and proceeds if it returns true. If the returnType is not given then it defaults to "update-page" and sets it on the data which will be submitted to the server. It then calls the invokeAjaxReturnHandler() to determine which handler function to call. The successCallback and errorCallback are handled as they were before in ajaxSubmitForm(). The elementToBlock and the lightBox processing remain the same.

5. submitForm() -  This is used for non-ajax calls. This in turn calls the submitFormFullOpts() with the validate flag set to false.

6. validateAndSubmitForm() - This is used for non-ajax calls. This in turn calls the submitFormFullOpts() with the validate flag set to true.

7. submitFormFullOpts() - Does a non ajax submit. The data-attributes that are passed in as additional data are written as hidden params to the form before it is submitted.

8. invokeAjaxReturnHandler() - This method iterates over divs in the content that is passed in to determine which handler functions to call. The handler functions are initialized in krad.initialize.js

9. updatePageHandler() - Called if the returnType is "update-page". Finds the page content in the returned content and updates the page, then processes breadcrumbs and hidden scripts. While processing, the page contents are hidden (works similar to the the updatePageCallback()).

10. updateViewHandler() - Replaces the view with the given content and runs the hidden scripts. Called when the returnType is "update-view".

11. redirectHandler() - Called when the returnType is "redirect". Replaces the contents of the window with those of the redirected URL.

12. updateComponentHandler() - Called when the returnType is "update-component". Retrieves the component with the matching id from the server and replaces a matching  _refreshWrapper marker span with the same id with the result.  In addition, if the result contains a label and a displayWith marker span has a matching id, that span will be replaced with the label content  and removed from the component.  This allows for label and component content seperation on fields (Works the same as updateRefreshableComponentCallback)

Changes and removal of some methods in DictionaryValidationService (KRAD version) and ViewValidationService as a result of State based validation

Please see these classes for the changes made here.  Some method signatures were changed for this support and some methods were removed for clarity.

KULRICE-7485 - Refactoring of Session Form Handling

Previously to clear (or reset) form properties between requests the postBind form method could be implemented. This method has been removed in M2. Now to indicate a property should not be persisted in session (thus reset for each request) the annotation @SessionTransient should be added before the property declaration.

KULRICE-7527 - Removal of some default nested beans

To help with performance, some nested beans that were being initialized in the XML were pulled out. In the code, if determined the component is needed, a call is made to then initialize the bean.

This means for these removed beans, if you were using the nested notation to set a property (for example, 'nested.property'), this will now throw an exception. You must first initialize the nested bean, then set the property. Note in cases where the default initialization was removed, a top level bean was created making it easy to initialize if needed.

The following nested beans were removed:

Example Conversion

<bean parent="Uif-VerticalBoxSection"> 
    <property name="header.upperGroup.items">   
        <list>    ...   </list> 
    </property>
</bean> 

change to

<bean parent="Uif-VerticalBoxSection">
    <property name="header.upperGroup">
        <bean parent="Uif-HeaderUpperGroup">
            <property name="items">
                <list>          ...       </list>     
            </property>   
        </bean> 
    </property>
</bean>

KULRICE-7351 - JSP Templates converted to FreeMarker

For performance reasons the KRAD JSP templates were converted to use the FreeMarker templating language. Any custom components (or template overrides) that were created will need to be converted to FreeMarker.

See this page for a comparison of JSP and FreeMarker: https://wiki.kuali.org/display/KULRICE/Freemarker+and+JSP+comparison

Templates are associated with a component (bean) using two properties now. The first is the template property which gives the location of the template source. The second is the templateName property which is the name of the template to invoke (in FreeMarker this is the macro name). If you override one of the default templates, make sure to also give the template a unique templateName.

KULRICE-7246 - Default escapeHtmlInPropertyValue to True

For security reasons the escapeHtmlInPropertyValue property on DataField was defaulted to true. Therefore if you have a property which has HTML that should be rendered, you will need to set this property to false on the data field.

Loading the view object from bean definitions can take up to 4 or 5 seconds in some cases (although this is improving with the removal of default nested beans). To boast performance, an enhancement was put in to 'pre-load' the view objects. This means when the application starts up, it will fetch one or more view objects for a particular view and hold until a request is made. The number of views to preload is configured by the view property preloadPoolSize. This is set to 1 by default for all views except lookups and inquiries.

Setting Preload Pool Size

<bean id="CourseView" parent="Uif-FormView"> 
    ... 
    <property name="preloadPoolSize" value="3"/>
</bean>

The views are loaded in a separate thread so the startup time is not impacted. Whenever a request for a view is made, a view from the pool is returned and a new view object is pulled in a separate thread to replace it. If no view objects exist in the pool at the time of a request, a call is made to build the view object. For high load views you can experiment with increasing the pool size so that a view is always available (Note a log statement is made when a view is not available from the pool, thus this can be used to help tune the parameter).

Note though storing the preloaded view objects consumes memory. In Rice (with Sampleapp) the storage was 91mb (and Rice does not have many views compared to what other applications like the KFS would). 

In previous versions of Rice a user can keep requested view objects whose forms get added to the user session (note this is only for views that have session persistence enabled). Although there are clear points implemented, they do not catch many exit actions. Therefore more and more memory continues to be consumed, even though the user might be long done with the form. 

To prevent this problem a configuration parameter was introduced that limits the number of forms per user session. The parameter name is maxNumberOfSessionForms and is set to 5 by default. This parameter can be tuned as needed however it is not recommended to go lower than 5 (think of nested lookups that might take place from a view).

Setting Max Form Storage Size in your rice config XML:

<param name="maxNumberOfSessionForms">10</param>

Whenever the number of session forms is greater than the configured maximum allowed, a form will be removed from the session. For determining which form to remove in these situations, the forms are arranged according to when they were accessed. In other words, the form whose last requested action time is oldest will be removed (most recently accessed forms will be kept). 

Instructions on how to run the scripts to apply these database changes are in the Upgrade Guide in this document

AjaxAction and its bean Uif-AjaxActionButton was removed. All bean references should change to use 'Uif-PrimaryActionButton' (ajax is the default now). The bean update script can be run to apply this change.

Property validatedLineActions on CollectionGroup was removed. Now actions that are defined in lineActions can have the property 'performClientSideValidation' flag set to true to indicate the line should be validated.

Property labelKey of BaseConstraint (and therefore all constraints) was renamed to messageKey. The bean update script can be run to apply this change.

Property baselinePackages of DataDictionaryService was renamed to additionalDictionaryFiles. In addition changed from a List<String> to Map<String, List<String>> where the map key is the namespace the dictionary beans should be associated with.