Migration Consideration from v4
| Warning |
|---|
If you are upgrading from v4 to v5 please read and understand the following migration notes which may require your action. |
...
If you have any questions please email support@frevvo.com
Database Configuration
MySQL database encoding utf8_general_ci
v5 requires utf8_unicode_ci encoding. MySQL supports two types of utf8 encoding: general and unicode. If your database is utf8_general_ci you must first switch the databases to utf8_unicode_ci and then proceed with the normal migration instructions.
Business Rules
Rules in v4 forms may show validation errors after the migration to v5. It is recommended that you correct these errors but, if you do not, the rules in the upgraded forms will still work without the corrections. Refer to the Rules Validator documentation for more information.
Custom Themes
The v4 global themes called Clear and Professional Blue have been replaced by Nouveau and Nouveau Blue. Custom themes created in v4 require manual migration in order to use them in v5.
...
Also see the migration considerations Styling Considerations topic below.
Spaces
A theme applied to a Space in v5, is propagated to all the forms in that space. If you want to use a different theme for a particular form or flow, you must override it by using the URL parameter, _themeId. For Example: http://demo4.frevvo.com:8082/frevvo/web/tn/{tn.id}/user/designer/app/_N4cF4ZuwEeCwk5wyBHqHrQ/flowtype/_BRD_MHxkEeKJS-B6PtnIKQ?_method=post&embed=true&_themeId=Nouveau. In v4 the space theme did not override the form's theme.
Form Designer
Format As
The control property "format as" on controls from XSD schema has been renamed to "display as". The behavior is the same. Only the property name has changed.
Required Controls from XSD
The v4 documentation described a work-around for Required Controls from XSD Data Source. This is a non standard approach to solving an issue that should be solved in the underlying XSD data source. v5 contains many enhancements for creating forms from XSD data source and has standardized XSD support. This non standard use described in the v4 documentation is no longer supported.
Styling Considerations
Option Width
The v5 default font has changed. has identified the following areas that should be checked and adjusted manually by the designer, if necessary.
...
| Note |
|---|
The v4 Themes documentation recommended 90% Option Width. If you followed that recommendation you won't likely hit this migration consideration. |
Grid Layouts with Blank Message Controls
| Info |
|---|
We highly recommend that you update any forms where you used the v4 panel layout custom theme to create a grid layout and replace these grids with the new Table Control. |
...
You can solve this either by replacing the panel grid with a new table control or by changing the content of the message control from <div style="text-align: right"/> to <br/>.
Tab Control
| Section | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
Tab look & feel has changed. If you used a custom style for font label size on a tab you may have to adjust the font label size on the Style tab of the Form Property panel.
|
Styles using em to set the width
Styles that used the HTML tag, em, to set a width will be larger in v5 then in v4 due to the fact that the default font size is now larger. Em is based on the font size. So 10em for example in a larger font will take up more width then 10em on a smaller font. This will effect the space used by all labels where the designer used em. For example, trigger controls will start taking up more width.
You can go back to your form and reduce the <n>em
Internationalization
New Strings in Default Locale Properties File
There are new strings present in the default locale properties file for forms/flows in v5. For example.: strings for mobile devices. You will need to manually add these new strings to your uploaded locale files for forms created in v4. New strings can be found by downloading the v5 default properties file for your form. Server wide customizations can be done by unzipping the <frevvo-home>/tomcat/webapps/frevvo.war. See this documentation for the details.
Data API
The browser doc feature in v4 is no longer supported. It introduced a new doc action that can be enabled by the API and where, on submission, the XML document would be sent back to the browser with the HTTP response. This enabled the capture of updated XML and make sure it updated their own systems in a single db transaction.
In 5.x, we have a new mechanism. It is possible now to submit forms using the API and receive back a DataSource? with multiple parts (multipart/form-data) one for each submission document: XML, snapshot, attachments, etc. This is above and beyond what the browser docs provide, but much simpler. See API's submitInstance() and Data Source documentation (coming soon...).
Dates & Time Initialization in a form.load Rule
Rules initializing dates & time will not work in a form.load rule unless you specify a timezone on the form's Url via the _formTz Url parameter. This is because the form server needs to know the timezone in which to return the date and time. If you do not specify a _formTz the methods will return null and the control values will remain blank. Timezone strings you can use in the parameter can be found here. For example, to specify Eastern time append &_formTz=America/NewYork to the form Url.